| 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
| 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 |