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 20140414162746.GW4161@awork2.anarazel.de
Whole thread Raw
In response to Re: Signaling of waiting for a cleanup lock?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 2014-04-14 12:02:22 -0400, Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > On 2014-04-14 11:30:02 -0400, Tom Lane wrote:
> >> 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?
> 
> Well, we already have locktags for relation pages, so that aspect isn't
> that hard.  The bigger problem is what are we waiting *for*, that is,
> what is it that blocks the lock request from being granted?

> In an ideal world, when we needed to wait for a cleanup lock, we'd cause
> the lock manager to set up pre-granted sharable page locks for all the
> processes currently holding buffer pins, and then wait for an exclusive
> page lock.

Well, wouldn't that imply every pin (well, unless local) goes through
the lock manager in some way because otherwise we'll end up with
basically the same kludges as today painted in a different color? I
can't believe that'll easily work out performancewise.

I think it might be worthwile to do this if we can figure out how to do
it performantly, but I won't hold my breath for it. And I think we need
to improve visibility of cleanup locks (and possibly lwlocks) on a much
shorter timescale.

> I'm not sure it's really worth the trouble to try to do
> this, but it would solve the visibility problem; and it might allow us to
> be a bit smarter about the priority of a cleanup lock request versus
> incoming regular pin requests.

I don't know how, but some smarter priorization here would be really
helpful. It pretty much sucks that some relation essentially can't be
vacuumed once there's tuples needing freezing.
I wonder if we could make the freezing part work without a cleanup lock...

Greetings,

Andres Freund

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



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Signaling of waiting for a cleanup lock?
Next
From: Robert Haas
Date:
Subject: Re: Dynamic Shared Memory stuff