Re: autovacuum: automatically propagate updated parameters

> On 24 Jul 2026, at 10:33, Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> wrote:
>
> From the documentation:
>
> Parallel workers launched for Parallel Vacuum are using the same cost
> delay parameters as the leader worker. If any of these parameters are
> changed in the leader worker, it will propagate the new parameter
> values to all of its parallel workers.
>
> But in practice, parallel_vacuum_propagate_shared_delay_params was
> only called during config reload. Otherwise when the leader adjusted
> the parameters, it didn't share them with the other workers.
>
> See the attached patch which adds a test case about this and adds an
> additional parallel_vacuum_propagate_shared_delay_params call to the
> update logic.

I reviewed this today and I agree with the proposed fix. The alternative would
be to update the documentation to match the reality of requiring a configuration
reload, but that brings on other baggage so I think fixing the code is the
better option here.

The part that worry me is the below testcode. The relation 'filler' is sized
large enough to outlast the test:

+# second worker's table: no indexes, no cost reloptions (participates in
+# balancing), sized to outlast the test
+$node->safe_psql(
+ 'regress_db2', qq{
+ CREATE TABLE filler (id int, pad text) WITH (autovacuum_enabled = false);
+ INSERT INTO filler SELECT g, repeat('x', 100) FROM generate_series(1, 200000) g;
+});

This is then used for two test cases, the first one has legitimate value:

+my $log = slurp_file($node->logfile, $log_offset);
+my @limits =
+ $log =~ /parallel autovacuum worker updated cost params: cost_limit=(\d+),/g;
+note("parallel worker cost_limit sequence: @limits");
+is($limits[0], '100',
+ 'parallel workers see the rebalanced cost limit');

The second seems less exciting.

+my $filler_running = $node->safe_psql('regress_db2',
+ "SELECT count(*) FROM pg_stat_progress_vacuum WHERE relid = 'filler'::regclass");
+is($filler_running, '1', 'second autovacuum worker was still running');

My worry is that this seems very timing dependent and risk being flaky in the
buildfarm where every unsuspected timing window known to man tends to happen on
a regular basis. Given the first test for the DEBUG2 log output, do we lose
all that much coverage if we cut the suite short after that, and reduce the
size of filler? Reducing the resources needed to run the test and the
potential for red builds in the BF seems like a win.

--
Daniel Gustafsson