Andres Freund <and...@2ndquadrant.com> writes:
> On 2014-04-14 15:45:45 +0100, Simon Riggs wrote:
>> On 13 April 2014 16:44, Andres Freund <and...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
