Manfred Koizar <mkoi-pg@aon.at> writes:
> On Thu, 13 Jan 2005 00:39:56 -0500, Tom Lane <tgl@sss.pgh.pa.us>
> wrote:
>> A would-be deleter of a tuple would have to go and clear the "known
>> good" bits on all the tuple's index entries before it could commit.
>> This would bring the tuple back into the "uncertain status" condition
>> where backends would have to visit the heap to find out what's up.
>> Eventually the state would become certain again (either dead to
>> everyone or live to everyone) and one or the other hint bit could be
>> set again.
> 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, since resetting the hint only forces other
transactions to go back to the original data (the tuple header) to
decide what to do. AFAICS the above is safe; I'm just pretty dubious
about the cost.
> AFAICS we'd need two new bits: "visible to all" and "maybe dead".
No, you've got this wrong. The three possible states are "known visible
to all", "known dead to all", and "uncertain". If you see "uncertain"
this means you have to go to the heap and compare the XIDs in the tuple
header to your snapshot to decide if you can see the row or not. The
index states are not the same as the "known committed good" or
"known committed dead" hint bits in the tuple header --- those can be
set as soon as the inserting/deleting transaction's outcome is known,
but we can't move the index entry into the "visible to all" or "dead to
all" states until that outcome is beyond the GlobalXmin event horizon.
regards, tom lane