On Mon, Apr 14, 2014 at 1:26 PM, Andres Freund <andres@2ndquadrant.com> wrote:
> 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.
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.1200956464@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
