Re: Signaling of waiting for a cleanup lock? - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Signaling of waiting for a cleanup lock?
Date
Msg-id 20140413154439.GQ4161@awork2.anarazel.de
Whole thread Raw
In response to Re: Signaling of waiting for a cleanup lock?  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Signaling of waiting for a cleanup lock?
Re: Signaling of waiting for a cleanup lock?
List pgsql-hackers
On 2014-04-12 17:40:34 -0400, Robert Haas wrote:
> On Fri, Apr 11, 2014 at 10:28 AM, Andres Freund <andres@2ndquadrant.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.

Overwriting parts of the query/activity sounds like it'd be somewhat
expensive ugly.

> I think we've avoided doing
> this for LWLocks for fear that there might be too much overhead, but
> it's hard for me to imagine a workload where you're waiting for
> cleanup locks often enough for the overhead to matter.

Hm. I am not sure I see the cost as a very compelling thing here. Sure,
we can't list the acquired lwlocks and such, but it should be cheap
enough to export what lwlock we're waiting for if we're going to
sleep. I think it'd be worthwile making that visible somehow.
But that's a separate issue...

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Window function optimisation, allow pushdowns of items matching PARTITION BY clauses
Next
From: Andres Freund
Date:
Subject: Re: test failure on latest source