Re: serializable lock consistency - Mailing list pgsql-hackers

On Mon, Dec 20, 2010 at 9:11 AM, Florian Pflug <fgp@phlo.org> wrote:
> 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
updatesthe tuple. You can't retroactively make a regular update on behalf of the locking transaction that committed
already,or concurrent selects would see the same row twice, but it might work with some kind of a magic tuple that's
onlyfollowed through the 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? 

My first reaction to all of this is that it sounds awfully grotty.

> 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. 

Even in the original version of this patch, there's a non-trivial
overhead here when a multi-xid exists that doesn't exist today: a
serializable transaction has to grovel through the XIDs in the
multi-xact and figure out whether any of them are new enough to be a
problem.  I fear that this whole approach is a case of trying to jam a
square peg through a round hole.  We're trying to force the on-disk
format that we have to meet a requirement it wasn't designed for, and
it's looking pretty ugly.  Kevin Grittner's work is a whole different
approach to this problem, and while that's obviously not fully
debugged and committed yet either, it's often easier to design a new
tool to solve a particular problem than to make an existing tool that
was really meant for something else do some new thing in addition.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company