On Dec20, 2010, at 13:13 , Heikki Linnakangas wrote:
> One way to look at this is that the problem arises because SELECT FOR UPDATE doesn't create a new tuple like UPDATE
does.The problematic case was:
>
>> T1 locks, T1 commits, T2 updates, T2 aborts, all after T0
>> took its snapshot but before T0 attempts to delete. :-(
>
> If T1 does a regular UPDATE, T2 doesn't overwrite the xmax on the original tuple, but on the tuple that T1 created.
> So one way to handle FOR UPDATE would be to lazily turn the lock operation by T1 into a dummy update, when T2 updates
thetuple. You can't retroactively make a regular update on behalf of the locking transaction that committed already, or
concurrentselects would see the same row twice, but it might work with some kind of a magic tuple that's only followed
throughthe ctid from the original one, and only for the purpose of visibility checks.
In the case of an UPDATE of a recently locked tuple, we could avoid having to insert a dummy tuple by storing the old
tuple'sxmax in the new tuple's xmax. We'd flag the old tuple, and attempt to restore the xmax of any flagged tuple with
anaborted xmax and a ctid != t_self during scanning and vacuuming.
For DELETEs, that won't work. However, could we maybe abuse the ctid to store the old xmax? It currently contains
t_self,but do we actually depend on that?
FOR-SHARE and FOR-UPDATE locks could preserve information about the latest committed locker by creating a multi-xid.
ForFOR-SHARE locks, we'd just need to ensure that we only remove all but one finished transactions. For FOR-UPDATE
locks,we'd need to create a multi-xid if the old xmax is >= GlobalXmin, but I guess that's tolerable.
best regards,
Florian Pflug