[PATCH] Use bounded GIN pending-list cleanup in parallel autovacuum
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t253871psql -h localhost -U postgresBuilt from patchset v1 (message #1), September 20, 2026 at 03:51 PM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t253871_1 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t253871_1 && git checkout t253871_1Patchset v1 (message #1) is on t253871_1
Hi,
GIN asks a manual VACUUM to empty the pending list. Autovacuum instead
stops after processing the part of the list that existed when cleanup
started. This prevents concurrent insertions from extending cleanup
indefinitely. It is safe because those insertions cannot contain TIDs
that this VACUUM needs to remove.
Parallel autovacuum workers are regular background workers, so
AmAutoVacuumWorkerProcess() returns false for them. A GIN index handled
by such a worker is therefore treated as if it were processed by a
manual VACUUM, and its pending-list cleanup is not bounded.
The attached patch adds is_autovacuum to IndexVacuumInfo and passes the
leader's state to parallel workers. GIN uses that state when deciding
whether the pending list must be emptied. Manual VACUUM behavior is
unchanged.
Any thoughts?
---
Best regards,
Jingtang Zhang