| 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 |
| 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 |