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 по дате отправления: