Re: [PATCH] Use bounded GIN pending-list cleanup in parallel autovacuum

Hi Jingtang,

On Sep 20, 2026, Jingtang Zhang wrote:
> The attached patch adds is_autovacuum to IndexVacuumInfo and passes
> the leader's state to parallel workers.

I read v1 and think this is the right approach. The cleanup policy
should belong to the VACUUM operation, not depend on which process
happens to pick up an index. Passing it through IndexVacuumInfo keeps
that distinction explicit. I checked the core callers and did not
find a missing initialization of the new field.

I also reviewed the other uses of AmAutoVacuumWorkerProcess() and found
no other cases of this confusion. The check in ginInsertCleanup() is
OK: parallel_vacuum_main() sets maintenance_work_mem to the worker's
share of the leader's budget. We cannot assert !IsParallelWorker()
in the macro, since callers such as vacuum_delay_point() need to
distinguish the leader from its workers. Perhaps a comment at the
macro definition noting that autovacuum's parallel workers return
false would help prevent similar mistakes.

I also checked this against 8637383f5ff, the recent fix for pending-list
cleanup during multiple index-vacuum passes. The requirement there is
to process the existing pending entries before each ginbulkdelete()
pass. This patch preserves that, including forceCleanup=true so that
we wait for a concurrent cleanup. Extending the existing bounded
behavior to the parallel workers does not weaken that guarantee.

Could we cover the parallel-worker path with a test? One possible
scenario is to pause cleanup while flushing the old tail into the main
index, append new pending pages, and verify that cleanup leaves those
new pages behind. The test would need to ensure that a parallel worker,
not the leader, handles the index; otherwise it could pass without
the fix. I have not tried this scenario yet.

Thank you!

Best regards, Andrey Borodin.