Scenario:
Transaction T1 updates a given tuple -- xmax is set to T1 on that tuple
...
later on, T1 aborts... we believe that in this circumstance HEAP_XMAX_INVALID should be set on the tuple to signal that the tuple was not actually "deleted" by T1 since this aborted.
The question is:
Where is HEAP_XMAX_INVALID set on the tuple?
We have dag around the code and we have noticed (e.g., heap_update, lines 1963-19673) that when a transaction T2, waiting for T1 to release the lock on the tuple, gets woken up by T1 abort, checks whether T1 did commit and in the negative takes care of updating the tuple infomask.
Does this mean that in case of T1 abort, nobody explicitly updates the infomask hint bits of the tuples "deleted" by T1? Otherwise, I guess it would not make any sense to have following transactions do this work.
On the other hand, this seems to me not sufficient (unless I am missing something of course : ). What if there were no transactions waiting for a lock on a tuple "deleted" by T1? In this case nobody would set HEAP_XMAX_INVALID on T1 tuples? This would mess up things also for what concerns snapshot visibility related functions which do check infomask's HEAP_XMAX_INVALID to determine tuple visibility (i.e. to understand if the xmax transaction has committed or not).
Summing up, HEAP_XMAX_INVALID is set by some functions explicitely called to handle the abort or this work is done only by following transactions subsequently accessing the tuple?
Thanks a lot in advance!
Letizia
Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com
