Re: Incorrect result of bitmap heap scan.
Peter Geoghegan <pg@bowt.ie>
From: Peter Geoghegan <pg@bowt.ie>
To: Andres Freund <andres@anarazel.de>
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
Matthias van de Meent <boekewurm+postgres@gmail.com>, Konstantin Knizhnik <knizhnik@garret.ru>,
PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2024-12-02T17:15:19Z
Lists: pgsql-hackers
On Mon, Dec 2, 2024 at 11:52 AM Andres Freund <andres@anarazel.de> wrote: > I think the problematic scenario involves tuples that *nobody* can see. During > the bitmap index scan we don't know that though. Right, exactly. FWIW, this same issue is why it is safe for nbtree to drop its pin early during plain index scans, but not during index-only scans -- see _bt_drop_lock_and_maybe_pin, and the nbtree/README section on making concurrent TID recycling safe. Weirdly, nbtree is specifically aware that it needs to *not* drop its pin in the context of index-only scans (to make sure that VACUUM cannot do unsafe concurrent TID recycling) -- even though an equivalent index scan would be able to drop its pin like this. 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). -- Peter Geoghegan
Commits
-
Add test for HeapBitmapScan's broken skip_fetch optimization
- 24da5b239a4b 18.0 landed
-
Remove HeapBitmapScan's skip_fetch optimization
- 459e7bf8e2f8 18.0 landed
- b9ec8125d167 13.21 landed
- 4934d38759cd 14.18 landed
- 77d90d6d6334 15.13 landed
- 980727b84107 16.9 landed
- 78cb2466f752 17.5 landed
-
Allow bitmap scans to operate as index-only scans when possible.
- 7c70996ebf09 11.0 cited