Re: vacuum verbose no longer reveals anything about pins - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: vacuum verbose no longer reveals anything about pins
Date
Msg-id CAH2-WznQicOf8+3dYis6HbA70+oLuVN7n1ZO2S=Y+4h6WdY_=g@mail.gmail.com
Whole thread Raw
In response to Re: vacuum verbose no longer reveals anything about pins  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Thu, Jun 30, 2022 at 8:43 AM Robert Haas <robertmhaas@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



pgsql-hackers by date:

Previous
From: Steve Chavez
Date:
Subject: Re: Add red-black tree missing comparison searches
Next
From: Bruce Momjian
Date:
Subject: Re: Hardening PostgreSQL via (optional) ban on local file system access