Re: Signaling of waiting for a cleanup lock? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Signaling of waiting for a cleanup lock?
Date
Msg-id CA+TgmoZG01uGL2TV6KOjmax-53eT3J66nk1KSkuOsPysz=DQ2A@mail.gmail.com
Whole thread Raw
In response to Re: Signaling of waiting for a cleanup lock?  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Signaling of waiting for a cleanup lock?
Next
From: Heikki Linnakangas
Date:
Subject: Re: Race condition between PREPARE TRANSACTION and COMMIT PREPARED (was Re: Problem with txid_snapshot_in/out() functionality)