On 2014-04-14 11:30:02 -0400, Tom Lane wrote: > 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.
Well, it's still better than the current situation of waiting and not signalling it to anything externally visible. I think Robert's suggestion of an additional waiting_on=lock,lwlock,bufferpin might be a realistic way forward. > 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). That'd be neat, but I am not really sure how? Which lock would we be waiting on? I don't really see heavyweight locks scaling up to buffer pins? Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
