Hi,
Sorry for the late reply. I didn't realize your report until now.
On Mon, Sep 21, 2026 at 11:28 AM Nikolay Samokhvalov <nik@postgres.ai> wrote:
>
> On Thu, Aug 27, 2026 at 3:43 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> > Thank you for taking care of it. The v3 patch looks good to me.
>
> AI found one more gap while testing the committed fix on REL_19_STABLE at
> b368bdd2. I haven't manually reviewed the code yet.
>
> Once an autovacuum leader enters WaitForParallelWorkersToFinish(), SIGHUP
> wakes its latch, but the loop only runs CHECK_FOR_INTERRUPTS(), leaving
> ConfigReloadPending set. A cost-limit rebalance is not signalled at all. In
> both cases, the leader does not publish changed cost parameters until the
> parallel worker finishes.
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.
Regards,
--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com
