On 2014-04-14 11:30:02 -0400, Tom Lane wrote:
> 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.
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