On Thu, 13 Jan 2005 00:39:56 -0500, Tom Lane <[EMAIL PROTECTED]> 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? In a previous post you wrote: | I think we still have one free bit in index tuple headers... AFAICS we'd need two new bits: "visible to all" and "maybe dead". Writing the three status bits in the order "visible to all", "maybe dead", "known dead", a normal index tuple lifecycle would be 000 -> 100 -> 110 -> 111 In states 000 and 110 the heap tuple has to be read to determine visibility. The transitions 000 -> 100 and 110 -> 111 happen as side effects of index scans. 100 -> 110 has to be done by the deleting transaction. This is the operation where the additional run time cost lies. One weakness of this approach is that once the index tuple state is 110 but the deleting transaction is aborted there is no easy way to reset the "maybe deleted" bit. So we'd have to consult the heap for the rest of the tuple's lifetime. Servus Manfred ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html