On Thu, Jun 30, 2022 at 8:43 AM Robert Haas <robertmh...@gmail.com> wrote: > Ah, I missed that. I think that in the test case I was using, there > was a conflicting pin but there were no dead tuples, so that line > wasn't present in the output.
Even if there was a DEAD tuple, your test would still have to account for opportunistic pruning before the cursor acquires its blocking pin (I'm guessing that you're using a cursor for this). The earlier pruning could turn the DEAD tuple into either an LP_UNUSED item (in the case of a heap-only tuple) or an LP_DEAD stub line pointer. As I said, any existing LP_DEAD items will get put in the dead_items array by lazy_scan_noprune, very much like it would in the cleanup-lock-acquired/lazy_scan_prune case. > Maybe nothing. I just thought you'd completely removed all reporting > on this, and I'm glad that's not so. The important idea behind all this is that VACUUM now uses a slightly more abstract definition of scanned_pages. This is far easier to work with at a high level, especially in the instrumentation code used by VACUUM VERBOSE. You may have also noticed that VACUUM VERBOSE/autovacuum logging actually shows the number of scanned pages in Postgres 15, for the first time -- even though that's very basic information. The revised definition of scanned_pages enabled that enhancement. We are no longer encumbered by the existence of a no-cleanup-lock-page special case. -- Peter Geoghegan
