Re: Signaling of waiting for a cleanup lock?
От | Tom Lane |
---|---|
Тема | Re: Signaling of waiting for a cleanup lock? |
Дата | |
Msg-id | 25688.1397489402@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Signaling of waiting for a cleanup lock? (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: Signaling of waiting for a cleanup lock?
|
Список | pgsql-hackers |
Andres Freund <andres@2ndquadrant.com> writes: > On 2014-04-14 15:45:45 +0100, Simon Riggs wrote: >> On 13 April 2014 16:44, Andres Freund <andres@2ndquadrant.com> wrote: >>> 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. >> pg_stat_activity.waiting = true > Yes. That's what I suggested above. The patch for it is trivial, but: > Currently - I think - everything that sets waiting = true, also has > contents in pg_locks. Not sure if it will confuse users if that's not > the case anymore. I think it will. This is a case where a quick and dirty hack is nothing but quick and dirty. I wonder whether we should not try to fix this by making the process wait on a heavyweight lock, if it has to wait. That would also get us out of the rather grotty business of using a special-purpose signal to wake it up. However, there's still a visibility problem, in that there'd be no way to tell which other processes are blocking it (which is the thing you *really* want to know). regards, tom lane
В списке pgsql-hackers по дате отправления: