Re: autovacuum: automatically propagate updated parameters

> On 24 Sep 2026, at 08:34, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:
> On Wed, Sep 23, 2026 at 5:39 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:

> > 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.

I was also looking at this thread over the past few days and I agree that this
seems too invasive for the issue at hand given where we are in the cycle.

> 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.

Agree, we should avoid polling loops like that as much as possible.

> 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.

It's not great to sprinkle in worker specific code in the generic parallel
handling. My original thinking was to reject the idea, but the vacuum costing
is already used for non-vacuum purposes (and there have been discussions to
rename and generalize it) so with that in mind I am less concerned for this
particular case.

I can verify that the posted reproducer is still fixed with this patch applied
(and it survives a check-world).

> 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.

Not sure I see a better solution either, and we are running short of time
before 19 RC1.

--
Daniel Gustafsson