Re: change in LOCK behavior

On 11 October 2012 20:25, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Thu, Oct 11, 2012 at 2:48 PM, Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>> 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.
>
> I agree with this. I think that the reversion that Tom is pushing for
> is fixing a very special case of a more general problem. Now, it
> might be a sufficiently important special-case that we ought to go and
> do the revert, but if your argument is that this is an unsatisfying
> band-aid, I couldn't agree more. It appears to me that this
> discussion is exposing the fact that we really haven't given much
> thought to when snapshots ought to be taken or to arranging the order
> of operations so that they are taken as late as is safely possible.
>
>> 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?
>
> Well, that's actually not safe either, at least if taken literally.

Right - I didn't mean that far - since it was me suggested deferring
snapshots previously I'm aware that doesn't work.

But immediately before we read the first heap row... since we might
need to wait on index access, heap I/O etc.

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