Re: Dealing with dangling index pointers

Heikki Linnakangas <heikki(at)enterprisedb(dot)com> 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