pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: Propagate rebalanced cost limit to parallel vacuum workers 2+ messages / 1 participants [nested] [flat]
* pgsql: Propagate rebalanced cost limit to parallel vacuum workers @ 2026-08-28 21:35 Daniel Gustafsson <dgustafsson@postgresql.org> 0 siblings, 0 replies; 2+ messages in thread From: Daniel Gustafsson @ 2026-08-28 21:35 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Propagate rebalanced cost limit to parallel vacuum workers AutoVacuumUpdateCostLimit() runs after each nap in vacuum_delay_point() and follows av_nworkersForBalance, but the new limit never reached the shared cost params in the vacuum DSM: propagation only required config reload. Parallel workers computed their delays from the stale limit, so a parallel autovacuum could run at up to twice the configured budget (or half of it) until the next SIGHUP, contradicting the propagation promise in maintenance.sgml. Call parallel_vacuum_propagate_shared_delay_params() after rebalancing. Gated on the leader: parallel workers take the same nap path and must not overwrite the shared parameters. This also adds a test to validate the behaviour: pause the leader at the existing injection point, start a second autovacuum worker and hold it at a new injection point placed after it joined the balance, then check the first parameter load of the parallel workers reports the balanced limit. The hold is needed because a second worker left running can finish its own vacuum before the leader resumes, which puts the balance back where it started. Autovacuum is disabled for everything but the two test tables via thresholds, as a worker spawned by catalog churn would get trapped at the hold point and starve the test of its second worker slot. Backpatch to v19 where autovacuum gained the ability to use parallel vacuum workers. Author: Zsolt Parragi <zsolt.parragi@percona.com> Reviewed-by: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com> Reviewed-by: Daniel Gustafsson <daniel@yesql.se> Discussion: https://postgr.es/m/CAN4CZFOZtEPwGQ6oa9LvHvN522zEp8h_dW9hHExSh7pVXofoKQ@mail.gmail.com Backpatch-through: 19 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/6c5f1d6074208146930b67c2054509c3e82f6f7f Modified Files -------------- src/backend/commands/vacuum.c | 3 + src/backend/postmaster/autovacuum.c | 1 + .../test_autovacuum/t/001_parallel_autovacuum.pl | 88 +++++++++++++++++++++- 3 files changed, 91 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 2+ messages in thread
* pgsql: Propagate rebalanced cost limit to parallel vacuum workers @ 2026-08-28 21:35 Daniel Gustafsson <dgustafsson@postgresql.org> 0 siblings, 0 replies; 2+ messages in thread From: Daniel Gustafsson @ 2026-08-28 21:35 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org Propagate rebalanced cost limit to parallel vacuum workers AutoVacuumUpdateCostLimit() runs after each nap in vacuum_delay_point() and follows av_nworkersForBalance, but the new limit never reached the shared cost params in the vacuum DSM: propagation only required config reload. Parallel workers computed their delays from the stale limit, so a parallel autovacuum could run at up to twice the configured budget (or half of it) until the next SIGHUP, contradicting the propagation promise in maintenance.sgml. Call parallel_vacuum_propagate_shared_delay_params() after rebalancing. Gated on the leader: parallel workers take the same nap path and must not overwrite the shared parameters. This also adds a test to validate the behaviour: pause the leader at the existing injection point, start a second autovacuum worker and hold it at a new injection point placed after it joined the balance, then check the first parameter load of the parallel workers reports the balanced limit. The hold is needed because a second worker left running can finish its own vacuum before the leader resumes, which puts the balance back where it started. Autovacuum is disabled for everything but the two test tables via thresholds, as a worker spawned by catalog churn would get trapped at the hold point and starve the test of its second worker slot. Backpatch to v19 where autovacuum gained the ability to use parallel vacuum workers. Author: Zsolt Parragi <zsolt.parragi@percona.com> Reviewed-by: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> Reviewed-by: Masahiko Sawada <sawada.mshk@gmail.com> Reviewed-by: Daniel Gustafsson <daniel@yesql.se> Discussion: https://postgr.es/m/CAN4CZFOZtEPwGQ6oa9LvHvN522zEp8h_dW9hHExSh7pVXofoKQ@mail.gmail.com Backpatch-through: 19 Branch ------ REL_19_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/4af0528a0e49d06b997c443b044cb013503e1546 Modified Files -------------- src/backend/commands/vacuum.c | 3 + src/backend/postmaster/autovacuum.c | 1 + .../test_autovacuum/t/001_parallel_autovacuum.pl | 88 +++++++++++++++++++++- 3 files changed, 91 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2026-08-28 21:35 UTC | newest] Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-08-28 21:35 pgsql: Propagate rebalanced cost limit to parallel vacuum workers Daniel Gustafsson <dgustafsson@postgresql.org> 2026-08-28 21:35 pgsql: Propagate rebalanced cost limit to parallel vacuum workers Daniel Gustafsson <dgustafsson@postgresql.org>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox