Re: Signaling of waiting for a cleanup lock?

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Signaling of waiting for a cleanup lock?
Date: 2014-04-13 15:44:39
Message-ID: 20140413154439.GQ4161@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(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.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2014-04-13 15:51:18 Re: test failure on latest source
Previous Message Tom Lane 2014-04-13 15:31:41 Re: Window function optimisation, allow pushdowns of items matching PARTITION BY clauses