On Mon, Aug 3, 2026 at 11:21 PM Kevin Rocker <me@kevinrocker.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.
