Re: autovacuum: automatically propagate updated parameters

From: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
To: Daniel Gustafsson <daniel(at)yesql(dot)se>
Cc: Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: autovacuum: automatically propagate updated parameters
Date: 2026-08-24 19:42:00
Message-ID: CALj2ACUPndic4sRgw2NZ7fzuS18Bwunq1ZqFhJaEK9Wfs4dpfA@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hi,

On Mon, Aug 24, 2026 at 5:31 AM Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
>
> > On 24 Jul 2026, at 10:33, Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> wrote:
> >
> > 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.

Nice catch! Yes, this needs to be fixed and backpatched to PG19
(1ff3180ca01). It misses propagating the changes made after the delay
update and requires one to reload the config. Mostly, the caller
doesn't know from outside whether the params have changed at all,
making the parallel workers for autovacuum not honor the cost params
at all.

How about propagating the params to parallel workers launched by
autovacuum right after updating cost limits in
AutoVacuumUpdateCostLimit()? With this change, the existing
propagate-upon-config-reload path could be removed. This looks
centralized and future-proof, unless I'm missing something. Thoughts?

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

I understand that having a test for this in the first place could have
helped catch this issue. However, I don't see a strong point in having
one now. Can we test it manually and get the fix alone?

--
Bharath Rupireddy
Amazon Web Services: https://aws.amazon.com

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Manuel Reyes Bravo 2026-08-24 19:42:59 Re: BUG #19638: Planner chooses an index-only scan for an index AM without amcanreturn, and execution fails
Previous Message Andrey Rachitskiy 2026-08-24 19:34:38 Re: BUG #19638: Planner chooses an index-only scan for an index AM without amcanreturn, and execution fails