I am studying the postgresql kernel and the following question arose... I hope somebody out there can help me find the
answersto my doubts.<br /><br /> Scenario:<br /><br /> Transaction T1 updates a given tuple -- xmax is set to T1 on
thattuple<br /> ...<br /> later on, T1 aborts... we believe that in this circumstance HEAP_XMAX_INVALID should be set
onthe tuple to signal that the tuple was not actually "deleted" by T1 since this aborted.<br /><br /> The question
is:<br/><br /> Where is HEAP_XMAX_INVALID set on the tuple?<br /><br /> 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.<br/><br /> 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.<br
/><br/> On the other hand, this seems to me not sufficient (unless I am missing something of course : ). What if there
wereno transactions waiting for a lock on a tuple "deleted" by T1? In this case nobody would set HEAP_XMAX_INVALID
onT1 tuples? This would mess up things also for what concerns snapshot visibility related functions which do check
infomask'sHEAP_XMAX_INVALID to determine tuple visibility (i.e. to understand if the xmax transaction has committed or
not).<br/><br /> Summing up, HEAP_XMAX_INVALID is set by some functions explicitely called to handle the abort or this
workis done only by following transactions subsequently accessing the tuple? <br /><br /> Thanks a lot in advance!<br
/><br/> Letizia<br /><p> Chiacchiera con i tuoi amici in tempo reale! <br />
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com