Andres Freund <and...@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. The current hack of signaling when you're the last one off the
page would be replaced by releasing your lock (if it exists) when you drop
your own pin. 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.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
