Re: Signaling of waiting for a cleanup lock?

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Signaling of waiting for a cleanup lock?
Дата
Msg-id 20140413154439.GQ4161@awork2.anarazel.de
обсуждение исходный текст
Ответ на Re: Signaling of waiting for a cleanup lock?  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Signaling of waiting for a cleanup lock?  (Amit Kapila <amit.kapila16@gmail.com>)
Re: Signaling of waiting for a cleanup lock?  (Simon Riggs <simon@2ndQuadrant.com>)
Список pgsql-hackers
On 2014-04-12 17:40:34 -0400, Robert Haas wrote:
> On Fri, Apr 11, 2014 at 10:28 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> > VACUUM sometimes waits synchronously for a cleanup lock on a heap
> > page. Sometimes for a long time. Without reporting it externally.
> > Rather confusing ;).
> >
> > Since we only take cleanup locks around vacuum, how about we report at
> > least in pgstat that we're waiting? At the moment, there's really no way
> > to know if that's what's happening.
> 
> That seems like a pretty good idea to me.

What I am not sure about is how... It's trivial to set
pg_stat_activity.waiting = true, but without a corresponding description
what the backend is waiting for it's not exactly obvious what's
happening. I think that's better than nothing, but maybe somebody has a
glorious better idea.

Overwriting parts of the query/activity sounds like it'd be somewhat
expensive ugly.

> I think we've avoided doing
> this for LWLocks for fear that there might be too much overhead, but
> it's hard for me to imagine a workload where you're waiting for
> cleanup locks often enough for the overhead to matter.

Hm. I am not sure I see the cost as a very compelling thing here. Sure,
we can't list the acquired lwlocks and such, but it should be cheap
enough to export what lwlock we're waiting for if we're going to
sleep. I think it'd be worthwile making that visible somehow.
But that's a separate issue...

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Window function optimisation, allow pushdowns of items matching PARTITION BY clauses
Следующее
От: Andres Freund
Дата:
Сообщение: Re: test failure on latest source