Release and unpin buffers after leaving CRIT section in GIN.

On Tue, Feb 17, 2026 at 02:58:24PM +0500, Kirill Reshke wrote:

Few places in GIN code does not follow that. v1 fixes it.

Yep. That sounds pretty much right. Thanks for the report.
--
Michael

On Tue, 17 Feb 2026 at 15:07, Michael Paquier <michael@paquier.xyz> wrote:

On Tue, Feb 17, 2026 at 02:58:24PM +0500, Kirill Reshke wrote:

Few places in GIN code does not follow that. v1 fixes it.

Yep. That sounds pretty much right. Thanks for the report.
--
Michael

Looks like there are two more instances of this on HEAD: in gistbuild
and log_newpage_range. Is it?

```
reshke@yezzey-cbdb-bench:~/cpg$ git diff
src/backend/access/gist/gistbuild.c
src/backend/access/transam/xloginsert.c
diff --git a/src/backend/access/gist/gistbuild.c
b/src/backend/access/gist/gistbuild.c
index 7f57c787f4c..8e0c083ffa7 100644
--- a/src/backend/access/gist/gistbuild.c
+++ b/src/backend/access/gist/gistbuild.c
@@ -305,10 +305,10 @@ gistbuild(Relation heap, Relation index,
IndexInfo *indexInfo)
                MarkBufferDirty(buffer);
                PageSetLSN(page, GistBuildLSN);

- UnlockReleaseBuffer(buffer);
-
END_CRIT_SECTION();

+               UnlockReleaseBuffer(buffer);
+
                /* Scan the table, inserting all the tuples to the index. */
                reltuples = table_index_build_scan(heap, index,
indexInfo, true, true,

            gistBuildCallback,
diff --git a/src/backend/access/transam/xloginsert.c
b/src/backend/access/transam/xloginsert.c
index d3acaa636c3..a9a1678acc9 100644
--- a/src/backend/access/transam/xloginsert.c
+++ b/src/backend/access/transam/xloginsert.c
@@ -1355,11 +1355,12 @@ log_newpage_range(Relation rel, ForkNumber forknum,
                recptr = XLogInsert(RM_XLOG_ID, XLOG_FPI);

                for (i = 0; i < nbufs; i++)
-               {
                        PageSetLSN(BufferGetPage(bufpack[i]), recptr);
-                       UnlockReleaseBuffer(bufpack[i]);
-               }
+
                END_CRIT_SECTION();
+
+               for (i = 0; i < nbufs; i++)
+                       UnlockReleaseBuffer(bufpack[i]);
        }
 }

```

--
Best regards,
Kirill Reshke

On Tue, Feb 17, 2026 at 03:14:45PM +0500, Kirill Reshke wrote:

Looks like there are two more instances of this on HEAD: in gistbuild
and log_newpage_range. Is it?

Planting an assertion in UnlockReleaseBuffer(), there are two extra
places that can be spotted:
- Most of the places reported by the regression tests seem to come
from gistplacetopage(), with UnlockReleaseBuffer() called for a
rootsplit. This case is actually OK to me, where the new buffers are
all unlocked with the root page locked. I have to admit that I am not
the best specialist ever on this one, so I may be missing something.
- ginHeapTupleFastInsert(), with UnlockReleaseBuffer() called before
GinGetPendingListCleanupSize(). This one is not in line, being
registered as buffer in a XLOG_GIN_UPDATE_META_PAGE record. We could
do better here.

Saying that, the cases of createPostingTree()@gindatapage.c, the three
in ginfast.c, the one in ginutil.c, the two in ginvacuum.c (one with
only unpins), and xloginsert.c are no-brainers to me, so I have
applied these.

The two proposed cases in gininsert.c and gistbuild.c do nothing
related to WAL-logging, though.
--
Michael