On 20.12.2010 13:52, Florian Pflug wrote:
On Dec20, 2010, at 07:16 , Heikki Linnakangas wrote:
On 19.12.2010 20:57, Florian Pflug wrote:
If we reuse the legacy field xvac to store xlast, we don't get into
trouble with binary upgrades either. We' need to find a way to deal
with tuples where HEAP_MOVED_IN or HEAP_MOVED_OUT is set, but that
seems manageable..
xvac shares the field with command id, and cid is in use while the tuple is
being updated.
Right :-(
Well, that nails this coffin shut pretty tightly, unless we were willing to add
another field to heap tuples.
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 the 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
only followed through the ctid from the original one, and only for the
purpose of visibility checks.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
