On Mon, Dec 2, 2024 at 12:15 PM Peter Geoghegan <p...@bowt.ie> wrote: > The underlying reason why nbtree can discriminate like this is that it > "knows" that plain index scans will always visit the heap proper. If a > TID points to an LP_UNUSED item, then it is considered dead to the > scan (even though in general the heap page itself might be marked > all-visible). If some completely unrelated, newly inserted heap tuple > is found instead, then it cannot be visible to the plain index scan's > MVCC snapshot (has to be an MVCC snapshot for the leaf page pin to get > dropped like this).
If I add "SET enable_indexonlyscan = false" to the "setup" section of the v1-0001-isolationtester-showing-broken-index-only-scans-w.patch isolationtester test case I posted earlier today, the test will pass. There is no reason to think that plain GiST index scans are broken. The fact that GiST VACUUM won't acquire cleanup locks is a problem *only* because GiST supports index-only scans (AFAIK no other thing within GiST is broken). My point is that index-only scans are generally distinct from plain index scans from an interlocking point of view -- they're not equivalent (not quite). And yet the "62.4. Index Locking Considerations" docs nevertheless say nothing about index-only scans in particular (only about bitmap scans). The docs do say that an MVCC snapshot is protective, though -- which makes it sound like GiST can't be doing anything wrong here (GiST only uses MVCC snapshots). Actually, I don't think that GiST would be broken at all if we'd simply never added support for index-only scans to GiST. I'm fairly sure that index-only scans didn't exist when the bulk of this part of the docs was originally written. ISTM that we ought to do something about these obsolete docs, after we've fixed the bugs themselves. -- Peter Geoghegan
