Re: Release and unpin buffers after leaving CRIT section in GIN.
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Kirill Reshke <reshkekirill@gmail.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2026-02-19T07:02:23Z
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
Commits
-
Sanitize some WAL-logging buffer handling in GIN and GiST code
- 21e323e941cf 19 (unreleased) landed