Re: Incorrect result of bitmap heap scan.
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Matthias van de Meent <boekewurm+postgres@gmail.com>, Konstantin Knizhnik <knizhnik@garret.ru>,
PostgreSQL Hackers <pgsql-hackers@postgresql.org>, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2024-12-02T16:46:50Z
Lists: pgsql-hackers
Hi, On 2024-12-02 11:07:38 -0500, Peter Geoghegan wrote: > Clearly it would be wildly impractical to do the "buffer pin interlock > against TID recycling" thing in the context of bitmap scans. That's certainly true if we do the VM check at the time of the bitmap heap scan. What if we did it whenever we first enter a block into the TID bitmap? There's sufficient padding space in PagetableEntry to store such state without increasing memory usage. That'd probably need some API evolution, because we'd only know after entering into the tidbitmap that we need to check the VM, we'd need to index pins during the VM checking and then update PagetableEntry with the result of the VM probe. I think, but am not certain, that it'd be sufficient to do the VM check the first time an index scan encounters a block. If a concurrent vacuum would mark the heap page all-visible after we encountered it first, we'd do "real" visibility checks, because the first VM lookup won't have it as all visible. And in the opposite situation, where we find a page all-visible in the VM, which then subsequently gets marked not-all-visible, normal snapshot semantics would make it safe to still consider the contents all-visible, because update/delete can't be visible to "us". Greetings, Andres Freund
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