Re: Parallel vacuum: workers together with leader could overrun cost budget

Hi,

On Wed, Oct 21, 2026 at 7:32 PM Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
>
> After reading v2, I have a small concern.
>
> In the VacuumSharedCostBalance != NULL path, the sleep cap is vacuum_cost_delay * 4 * nworkers. Say vacuum_cost_delay=100ms and nworkers=16; then the sleep time could be 6.4 seconds. Passing such a long delay to pg_usleep() seems concerning because its header comment explicitly says:

Nice catch! You are right. With a max cost delay of 100ms today, the
existing cap is no more than 400ms. And it looks like other
pg_usleep() callers in core will not wait more than 1s at once (except
the auth delays, which are developer options anyway). And per the
comment in WaitExceedsMaxStandbyDelay(), it seems that waiting more
than 1s with pg_usleep() is the "too long" beyond which backends lose
prompt response to latches and signals.

I think there are a couple of ways to handle this:

1/ Keep the cap at cost_delay * 4 * nworkers, but replace pg_usleep()
with WaitLatch() in 400ms steps (or even 1s steps).

2/ Cap the delay per worker at 1s (similar to
WaitExceedsMaxStandbyDelay()) i.e. Min(Min(msec, cost_delay * 4 *
nworkers), 1000). This still looks fine, and it's better than today's
400ms limit.

I prefer option 2, with a 1s cap per worker. Thoughts?

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