On 04.10.2013 13:23, Andres Freund wrote:
> On 2013-10-03 21:14:17 -0700, Dan Ports wrote:
>> On Thu, Oct 03, 2013 at 06:19:49AM -0700, Kevin Grittner wrote:
>>> Heikki Linnakangas<hlinnakangas@vmware.com> wrote:
>>>> IMHO it would be better to remove xmin from the lock key, and vacuum
>>>> away the old predicate locks when the corresponding tuple is vacuumed.
>>>> The xmin field is only required to handle the case that a tuple is
>>>> vacuumed, and a new unrelated tuple is inserted to the same slot.
>>>> Removing the lock when the tuple is removed fixes that.
>>
>> This seems definitely safe: we need the predicate locks to determine if
>> someone is modifying a tuple we read, and certainly if it's eligible
>> for vacuum nobody's going to be modifying that tuple anymore.
>
> But we're talking about freezing a tuple, not removing a dead tuple. I
> don't see anything preventing modification of a frozen tuple. Right?
Right, but if we no longer include xmin in the lock key, freezing a
tuple makes no difference. Currently, the problem is that when a tuple
is frozen, the locks on the tuple on the tuple are "lost", as the
xmin+ctid of the lock no longer matches xmin+ctid of the tuple.
Removing xmin from the lock altogether solves that problem, but it
introduces the possibility that when an old tuple is vacuumed away and a
new tuple is inserted on the same slot, a lock on the old tuple is
confused to be a lock on the new tuple. And that problem can be fixed by
vacuuming locks, when the corresponding tuple is vacuumed.
- Heikki
