On 2014-04-14 13:06:21 -0400, Tom Lane wrote: > 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.
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
