On 2014-04-14 13:06:21 -0400, Tom Lane wrote:
> Andres Freund <andres@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.
We only acquire cleanup locks in a blocking fashion from vacuum - and
vacuum has a pretty clearly defined locking behaviour. Additionally both
in vacuum and in opportunistic pruning there's only a very small and
defined amount of work done once the buffer is successfully pinned.
> 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.
You can? How? It could also be io or something else that's problematic.
> 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.
What's you opinion of the waiting = true combined with waiting_for =
'cleanup lock' or something similar?
Greetings,
Andres Freund
-- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services