Re: autovacuum: automatically propagate updated parameters

Hi,

On Wed, Sep 23, 2026 at 5:39 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
wrote:
>
> Good catch, we should fix it.
>
> > The other attached patch adds an optional callback to the worker-finish
> > wait. Parallel autovacuum uses it to handle reloads and poll cost-limit
> > rebalancing every 100 ms; other callers keep the existing behavior. It
also
> > adds tests for both cases to 001_parallel_autovacuum.pl.
>
> I've confirmed that the patch fixes the issue. While it works fine,
> I'm a bit concerned that adding
> WaitForParallelWorkersToFinishWithCallback() with a callback and a
> timeout might be overkill, as I don't see any usecase other than
> parallel autovacuum that needs to pass a callback.
>
> An alternative approach would be to have a function in
> vacuumparallel.c that waits for all index statuses to become
> PARALLEL_INDVAC_STATUS_COMPLETED while periodically checking for cost
> parameter updates. We still need the timeout there since nothing wakes
> up the leader on a cost limit rebalance. While it adds another wait
> loop before WaitForParallelWorkersToFinish(), that call should return
> almost immediately. We can consider adding a callback to
> WaitForParallelWorkersToFinish() when we find other use cases in the
> future.

Thanks for reporting the issue. I believe this issue can happen fairly
often in practice, especially when the autovacuum worker (leader) gets
smaller or fewer indexes than the parallel workers for index vacuuming
(workers), and the workers take longer than the leader (for example,
non-core indexes that can take a while). So I think we do need to fix it.

A separate wait function would lose all the cases that the existing wait
loop for parallel workers, WaitForParallelWorkersToFinish(), already
handles, like detecting error messages reported by the workers, their
liveness checks, attach/detach, and so on. It would also likely end up
duplicating that same logic along with the cost param update code at the
end.

I also don't like the wait-100ms-wakeup approach that a separate wait
function would run all the time, since it wastes power and CPU cycles.
Imagine a worker vacuuming an index that is hundreds of GBs or even TBs,
while the leader has only a small index and finishes first. The leader then
sits in the wait loop for longer until the large index is done, waking up
every 100ms the whole time. So I would prefer not to go that route.

How about doing the check inside the existing wait loop, only when the
process is an autovacuum worker, along the lines of the attached WIP? This
is simple, the pattern already exists elsewhere in the code, and it looks
safe. I also believe the wait loop is not in a performance-critical hot
path, and this check is not costly. I checked that it still fixes the
reported issues.

What I am less sure about is the fix for the second issue in the attached
WIP patch, which needs any leader waiting for its workers to be woken up
after the cost limit is rebalanced. I haven't found a better one yet.

PS: I noticed the attached v2 patch posted upthread only after finishing my
response.

Thoughts?

--
Bharath Rupireddy

Amazon Web Services: https://aws.amazon.com