> On Oct 23, 2026, at 03:30, Bharath Rupireddy
> <[email protected]> wrote:
>
> 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).
>
The header comment of pg_usleep() also suggests using WaitLatch() with a
timeout for long sleeps. However, one issue is that WaitLatch() takes a timeout
in milliseconds, while vacuum needs microsecond precision.
> 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.
>
Wouldn't the 1-second cap still allow the cost budget to be exceeded in some
cases, which is exactly what this patch is trying to fix? If so, wouldn't that
leave the fix incomplete?
> I prefer option 2, with a 1s cap per worker. Thoughts?
>
> --
> Bharath Rupireddy
> Amazon Web Services: https://aws.amazon.com
I'm thinking that maybe we could combine WaitLatch() and pg_usleep(). Use
WaitLatch() to sleep for the whole-millisecond portion, and leave the remaining
sub-millisecond portion to pg_usleep(), so we can preserve the precision
without sacrificing responsiveness.
The pseudocode would look something like this:
```
while (remaining_us > 0)
{
CHECK_FOR_INTERRUPTS();
if (remaining_us >= 1000)
{
(void) WaitLatch(MyLatch,
WL_LATCH_SET | WL_TIMEOUT | WL_EXIT_ON_PM_DEATH,
remaining_us / 1000,
WAIT_EVENT_VACUUM_DELAY);
ResetLatch(MyLatch);
}
else
{
pg_usleep(remaining_us);
}
/* Recalculate remaining_us. */
remaining_us = ...
}
```
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
