I've pushed patches fixing the issues discussed in this thread.
While I was working on it, it occurred to me that the whole darn mess
might be dead code as of the removal of SnapshotNow. The reason we're
doing this at all is the fear that, while some indexscan is in flight
from an index entry to the relevant heap tuple, VACUUM could remove
said tuple and then somebody else could insert a new, unrelated tuple
at the now-vacant TID. With ordinary MVCC snapshot checking, this
would not be a problem because the new tuple could not possibly
pass the snapshot check, so it wouldn't get returned. However, with
non-MVCC snapshots, it's possible we could return a heap tuple that
doesn't match the index qual. The fear of this happening for SnapshotNow
catalog accesses was what drove the original locking design, and that is
also why we don't bother with similar locking for other index types ---
only btree indexes are used for system catalog fetches.
So now that we use MVCC snapshots for system catalog fetches, it seems
like maybe we don't need to sweat about cleanup-locking index pages
we're not going to remove tuples from; indeed maybe we don't need to
acquire super-exclusive btree page locks at all.
I'm not totally sure about this; we still have SnapshotSelf for instance.
But maybe the remaining non-MVCC snapshot types are never used in ways
where this type of aliasing would be a problem, or maybe we could cause
that to become true with a bit more work.
I'm not planning to pursue the question myself at the moment, but
I thought I should mention it in case anybody else wants to.
regards, tom lane