On 07.10.2013 16:44, Kevin Grittner wrote:
> Heikki Linnakangas<hlinnakangas@vmware.com> wrote:
>
>> So I don't think you can ever get a false conflict because of
>> slot reuse.
>
> I spent some time looking at this, and I now agree.
>
>> And if there's a hole in that thinking I can't see right now, the
>> worst that will happen is some unnecessary conflicts, ie. it's
>> still correct.
>
> That is definitely true; no doubt about that part.
>
>> Summary: IMHO we should just remove xmin from the predicate lock
>> tag.
>
> I spent some time trying to see how the vacuum could happen at a
> point that could cause a false positive, and was unable to do so.
> Even if that is just a failure of imagination on my part, the above
> argument that it doesn't produce incorrect results still holds. I
> think the fact that I couldn't find a sequence of events which
> would trigger a false positive suggests it would be a rare case,
> anyway.
>
> I found the original bug report which led to the addition of xmin
> to the tag, and it was because we were still carrying tuple locks
> forward to new versions of those locks at the time. This was later
> proven to be unnecessary, which simplified other code; we
> apparently missed a trick in not removing xmin from the lock tag at
> that point. Since leaving it there has now been shown to *cause* a
> bug, I'm inclined to agree that we should simply remove it, and
> backpatch that.
>
> Patch attached. Any objections to applying that Real Soon Now?
> (When, exactly is the deadline to make today's minor release
> cut-off?)
A comment somewhere would be nice to explain why we're no longer worried
about confusing an old tuple version with a new tuple in the same slot.
Not sure where.
- Heikki
