Hi, On Wed, Oct 21, 2026 at 7:32 PM Chao Li <[email protected]> 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
