On Mon, Apr 14, 2014 at 1:26 PM, Andres Freund <and...@2ndquadrant.com> wrote: > 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.
Nevertheless, I'm pretty sure undetected deadlocks are possible; we've discussed it before. The TODO list contains a pointer to: http://www.postgresql.org/message-id/21534.1200956...@sss.pgh.pa.us I think the scenario is something like: vacuum is waiting for a buffer pin that pertains to an open query in some other session, which then tries to take a lock that conflicts with one already held by vacuum. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
