Re: Signaling of waiting for a cleanup lock?

On Mon, Apr 14, 2014 at 10:50 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> On 2014-04-14 15:45:45 +0100, Simon Riggs wrote:
>> On 13 April 2014 16:44, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
>> > On 2014-04-12 17:40:34 -0400, Robert Haas wrote:
>> >> On Fri, Apr 11, 2014 at 10:28 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
>> >> > VACUUM sometimes waits synchronously for a cleanup lock on a heap
>> >> > page. Sometimes for a long time. Without reporting it externally.
>> >> > Rather confusing ;).
>> >> >
>> >> > Since we only take cleanup locks around vacuum, how about we report at
>> >> > least in pgstat that we're waiting? At the moment, there's really no way
>> >> > to know if that's what's happening.
>> >>
>> >> That seems like a pretty good idea to me.
>> >
>> > 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.

In my personal opinion, it would be OK to change that, provided that
we have some real good documentation for it.

Longer-term, I'm wondering if we shouldn't have something like
pg_stat_activity.wait_type instead of pg_stat_activity.waiting. It
could be NULL when not waiting, or otherwise "lock", "lwlock", "buffer
cleanup", etc.

>> Easy to set the ps message also
>
> That actually makes it considerably more expensive since we'd need to
> save the old string somewhere. I am not sure it will be relevant, but
> it's not as easy a sell as just setting a single boolean.

Yeah, I'm not too sanguine about squeezing that part into 9.4.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company