Tom Lane wrote:
> Tom Lane <tgl@sss.pgh.pa.us> writes:
> > Manfred Koizar <mkoi-pg@aon.at> 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.
I am thinking we have to somehow lock the row while we set the index
status bit. We could add a new heap bit that says "my xid is going to
set the status bit" and put our xid in the expired location, set the
bit, then return to the heap and clear it.
Can we keep the heap and index page locked at the same time?
Anyway it is clearly something that could be an issue.
-- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610)
359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square,
Pennsylvania19073
