Re: Release and unpin buffers after leaving CRIT section in GIN.

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Kirill Reshke <reshkekirill(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Release and unpin buffers after leaving CRIT section in GIN.
Date: 2026-02-19 07:02:23
Message-ID: aZa1fwYFD3-4BrDP@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bertrand Drouvot 2026-02-19 07:06:13 Re: Flush some statistics within running transactions
Previous Message Hayato Kuroda (Fujitsu) 2026-02-19 06:58:33 RE: Selectively invalidate caches in pgoutput when pg_namespace is modified