Fix stale comment in parallel_vacuum_main().

From: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
To: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Cc: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Subject: Fix stale comment in parallel_vacuum_main().
Date: 2026-07-28 01:00:00
Message-ID: CALj2ACVwQ4WABqq8Lnf+VZEJ45jcTFhyFLFr_ctfS4=QLL-r5w@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

While working on the parallel heap vacuum feature I noticed a stale
comment in parallel_vacuum_main(). It says a parallel vacuum worker
must have only PROC_IN_VACUUM set because parallel index vacuum is not
supported for autovacuum. That is no longer true after commit
1ff3180ca01, which enabled autovacuum to use parallel vacuum workers.

IMHO, the assertion itself is still worth keeping. It ensures the
parallel worker carries PROC_IN_VACUUM, so that other backends ignore
its xmin when computing the removable-tuple horizon, which is what we
want for a worker that is part of a vacuum. The leader, whether it is
a backend running a VACUUM command or an autovacuum worker, sets
PROC_IN_VACUUM when it starts vacuuming the table, and the worker
inherits it when it imports the leader's snapshot (see
ProcArrayInstallRestoredXmin). PROC_IS_AUTOVACUUM never reaches the
worker, because parallel workers are launched as regular background
workers rather than autovacuum workers, so the flag is never set on
them, and importing the leader's snapshot doesn't carry it over
either. So the worker ends up with exactly PROC_IN_VACUUM even under
parallel autovacuum, and the assertion holds.

The attached patch rewords the comment to explain this. Since PG19 is
still in beta, I would like to backpatch this to 19 where 1ff3180ca01
was introduced.

Thoughts?

--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com

Attachment Content-Type Size
v1-0001-Fix-stale-comment-in-parallel_vacuum_main.patch application/octet-stream 2.0 KB

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2026-07-28 02:04:17 Re: [DESIGN] Soft DROP TABLE, recoverable drops for PostgreSQL
Previous Message Peter Smith 2026-07-28 00:52:00 Re: Support EXCEPT for ALL SEQUENCES publications