Andres Freund <and...@2ndquadrant.com> writes:
> On 2014-04-14 12:21:09 -0400, Robert Haas wrote:
>> AFAICS, the big advantage of something like this is that we'd get
>> proper deadlock detection, and that's not a trivial point.
> Hm. Is this actually something we need? I am not aware of deadlock prone
> scenarios involving buffer pins during normal processing (HS is another
> matter).
Ordinary buffer pinning isn't supposed to be subject to deadlocks (that's
why it's reasonable to use LWLocks for it), but it's less clear that
cleanup locks couldn't be subject to deadlocks.
The real issue here is that LWLocks support neither deadlock detection nor
state reporting, and that's more or less exactly why they're lightweight,
so we do not want to go in the direction of adding such features to them.
The cleanup-lock mechanism is sort of an ugly intermediate thing between
LWLocks and regular heavyweight locks. That was okay, sort of, as long
as it was simple ... but once we start loading additional feature
requirements onto it, it gets (even) less attractive to have a
single-purpose mechanism. In particular I'm not sold on the use-case
for being able to tell that a process is waiting without being able to
tell what it's waiting for. I can figure that much out already.
One concrete reason not to do the proposed trivial hack is that the lock
readout views are asynchronous. Right now, if someone sees a process that
claims to be waiting but they don't see any entry in pg_locks, they know
they saw inconsistent state. If we add a valid state where waiting can be
true without a pg_locks entry, they won't know what to think. I don't
want to go there.
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
