Tom Lane <[EMAIL PROTECTED]> writes:
> Manfred Koizar <[EMAIL PROTECTED]> writes:
>> Last time we discussed this, didn't we come to the conclusion, that
>> resetting status bits is not a good idea because of possible race
>> conditions?
> There's no race condition,
Actually, wait a minute --- you have a point. Consider a tuple whose
inserting transaction (A) has just dropped below GlobalXmin.
Transaction B is doing an index scan, so it's going to do something like
* Visit index entry, observe that it is in "uncertain" state.
* Visit heap tuple, observe that A has committed and is < GlobalXmin,
and there is no deleter.
* Return to index entry and mark it "visible to all".
Now suppose transaction C decides to delete the tuple. It will
* Insert itself as the XMAX of the heap tuple.
* Visit index entry, set state to "uncertain" if not already that way.
C could do this between steps 2 and 3 of B, in which case the index
entry ends up improperly marked "visible to all" while in fact a
deletion is pending. Ugh. We'd need some kind of interlock to prevent
this from happening, and it's not clear what. Might be tricky to create
such an interlock without introducing either deadlock or a big
performance penalty.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
