Re: change in LOCK behavior

On 11 October 2012 19:36, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Thu, Oct 11, 2012 at 2:23 PM, Simon Riggs <simon(at)2ndquadrant(dot)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.

Hmm, so now the patch author thinks his patch is not just broken with
respect to lock waits, but in all cases? Surely the above race
condition is obvious, now and before. Why is it suddenly unacceptable?
(If you believe that, why on earth did you commit?)

Whenever you take a snapshot things can change before you start using
it. And as a result all previous releases of Postgres suffer this
problem. Ergo, we should defer taking the snapshot until the very last
point when we need to use it. Why is that *not* being suggested here?

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services