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
From aba1a3b05cb55dd6ab32435b53dab7184caea221 Mon Sep 17 00:00:00 2001
From: Kevin Rocker <[email protected]>
Date: Mon, 3 Aug 2026 15:52:47 +0200
Subject: [PATCH v1 2/2] Additional vacuum_delay_point before flushing entries
to disk.
When flushing data to disk, there's a chance for a vacuum_delay_point
before the scan and the first insertion, in addition to after each insertion.
---
src/backend/access/gin/ginfast.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/src/backend/access/gin/ginfast.c b/src/backend/access/gin/ginfast.c
index 120f0705da0..2d3a7f27fef 100644
--- a/src/backend/access/gin/ginfast.c
+++ b/src/backend/access/gin/ginfast.c
@@ -919,6 +919,8 @@ ginInsertCleanup(GinState *ginstate, bool full_clean,
maxoff = PageGetMaxOffsetNumber(page);
LockBuffer(buffer, GIN_UNLOCK);
+ vacuum_delay_point(false);
+
/*
* Moving collected data into regular structure can take
* significant amount of time - so, run it without locking pending
--
2.54.0
