Re: change in LOCK behavior - Mailing list pgsql-hackers

From Robert Haas
Subject Re: change in LOCK behavior
Date
Msg-id CA+TgmoYjRaX8tqb9+phOTfRFK4ZwVs50qMds1DtsZ-6APr2QpQ@mail.gmail.com
Whole thread Raw
In response to Re: change in LOCK behavior  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: change in LOCK behavior  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
On Thu, Oct 11, 2012 at 2:23 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> So where's the race?
>
> AFAICS it either waits or it doesn't - the code isn't vague on that
> point. If we wait we set the flag.
>
> The point is that lock waits are pretty rare since most locks are
> compatible, so triggering a second snap if we waited is not any kind
> of problem, even if we waited for a very short time.

That actually wouldn't fix the problem, because we might have this scenario:

1. We take a snapshot.
2. Some other process commits, clearing its XID from its PGPROC and
releasing locks.
3. We take a lock.

:-(

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Simon Riggs
Date:
Subject: Re: change in LOCK behavior
Next
From: Tom Lane
Date:
Subject: Re: change in LOCK behavior