Re: [PATCH] Fix vacuum_delay_point happening inside lock

Hi Kevin,

On Mon, Aug 3, 2026 at 11:21 PM Kevin Rocker <me(at)kevinrocker(dot)com> wrote:

> Hi Neil,
>
> The `LockBuffer(buffer, GIN_UNLOCK)` you mentioned does call the vacuum
> delay as part of inserting each entry to disk, so the gain would be one
> additional delay_point before the scan and the first insertion. That unlock
> is also only in the flush-to-disk path, so it's not a direct replacement
> for the removed one.
>
> The unconditional part of the loop is 'processPendingPage' then release
> the buffer and call vacuum_delay right after the if/else. Given all that,
> it's probably fine as is? Let me know what you think. I've attached a patch
> with your suggestion as well.
>
> - Kevin Rocker

Thanks, that makes sense. I agree that the original patch is sufficient.

The additional call could improve cancellation responsiveness in the narrow
case where an interrupt becomes pending before the flush, but that window is
probably small, and the existing per-entry delay points already cover the
long-running part. So I have no objection to keeping the patch as is.

Best regards,
--
Ze Chen (Neil)
HighGo Software Co., Ltd.
https://www.highgo.com/