Re: Signaling of waiting for a cleanup lock?

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Signaling of waiting for a cleanup lock?
Date: 2014-04-14 16:27:46
Message-ID: 20140414162746.GW4161@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2014-04-14 12:02:22 -0400, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-04-14 16:33:27 Re: Dynamic Shared Memory stuff
Previous Message Robert Haas 2014-04-14 16:21:09 Re: Signaling of waiting for a cleanup lock?