Hi,
AI review identified an inconsistency in parallel vacuum (8e1fae1938).
I checked it myself and it is there on HEAD and on every branch since
PG15. Patch with a test attached. I don't think back-patching is
necessary as it's not a bug, only the context that gets reported.
The leader processes some of the indexes itself, through the same
function as the workers, parallel_vacuum_process_one_index(), and that
function records the index name for the error context, but only the
workers install the callback that reads it. The leader keeps the lazy
vacuum callback with whatever the heap scan last left there, so an
error it raises while vacuuming or cleaning up an index names the
table: "while scanning relation" for the index pass after the heap
scan and "while scanning block N of relation" for a pass in the middle
of it, where it should read "while vacuuming index ... of relation
...". Errors relayed from the workers get the same stale line
appended. Before 8e1fae1938 the leader went through
lazy_vacuum_one_index() and lazy_cleanup_one_index(), which set the
phase and the index name.
With PG19 this shows up in every autovacuum log once parallel
autovacuum is turned on, and that log line is often the only evidence
there is about which index a bad page belongs to.
The fix installs the parallel vacuum error callback in the leader for
as long as it processes indexes itself, and sets the heap scan phase
aside for that time so the stale line is not printed alongside it.
--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com
