Heikki Linnakangas <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> This is intentional --- consider case where VACUUM has removed both >> index and heap entries while some other (amazingly slow...) process is >> in flight from the index to the heap.
> Hmm. In b-tree we keep the index page pinned while we do the heap fetch > to avoid that, but apparently we don't have that interlock in other > indexams. Right. This is actually connected to the fact that only btrees are used as system catalog indexes, and so only btrees need to be safe for use with SnapshotNow semantics. If VACUUM has managed to remove the target tuple while we are "in flight", then it's further possible that someone else has inserted something new into that same tuple slot, and maybe even committed by the time we get there. Under SnapshotNow rules we would take the new tuple as a valid search result, though it (probably) doesn't actually satisfy the index search condition. With any MVCC-safe snapshot we will reject the new tuple as not meeting the snapshot. (BTW, this answers Teodor's question awhile back about whether he could use a GIN index in a system catalog. Nope, not without more work on index interlocking.) regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend