Thread: Tuple hint bits (INFOMASK) upon transaction abort
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
letizia leo <letizia_leo@yahoo.it> writes:
> 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
thatthe tuple was not actually "deleted" by T1 since this aborted.
Right. It is not T1's responsibility to do this, however. Rather, the
next transaction that examines the tuple will set the bit. That is
exactly the same as if T1 commits: it doesn't set XMAX_COMMITTED, the
next inspector of the tuple does.
To make this work, the pg_clog entry that says whether T1 committed or
aborted must be kept until all tuples modified by T1 have certainly been
marked as COMMITTED or INVALID. VACUUM is set up to track that.
regards, tom lane
"letizia leo" <letizia_leo@yahoo.it> wrote > > 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. > Not really. HEAP_XMAX_INVALID is a value of the hint bits, which helps to fast determine if a tuple is visible. The important thing is the header xmin, xmax, cmin, cmax stuff, which decides the visibility of the a tuple. When they are checked, current backend might be happy to set the hint bits so that other backends can fast determine its visibility with less job. So you can say even without these hint bits, Postgres won't make anything wrong, but may get slower. Regards, Qingqing