From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jeff Janes <jeff.janes@gmail.com>
cc: pgsql-bugs <pgsql-bugs@lists.postgresql.org>
Subject: Re: Bug with GIN index over JSONB data: "ERROR: buffer 10112 is not
 owned by resource owner"
In-reply-to: <1303019.1699590662@sss.pgh.pa.us>
References: 
 <CAMkU=1yCAKtv86dMrD__Ja-7KzjE=uMeKX8y__cx5W-OEWy2ow@mail.gmail.com>
 <1303019.1699590662@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
	message dated "Thu, 09 Nov 2023 23:31:02 -0500"
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="----- =_aaaaaaaaaa0"
Content-ID: <1877333.1699843262.0@sss.pgh.pa.us>
Date: Sun, 12 Nov 2023 21:42:27 -0500
Message-ID: <1877494.1699843347@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1877494.1699843347%40sss.pgh.pa.us>
Precedence: bulk

------- =_aaaaaaaaaa0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1877333.1699843262.1@sss.pgh.pa.us>

I wrote:
> Jeff Janes <jeff.janes@gmail.com> writes:
>> I was looking into a possible scalability problem with GIN indexes under
>> concurrent insert, but instead I found an uncharacterized bug. One of the
>> processes will occasionally throw an error  "ERROR:  buffer 10112 is not
>> owned by resource owner Portal" where the buffer number changes from run to
>> run.

> I am able to reproduce this in HEAD (8bfb231b4) on a not-that-big
> machine (M2 Mac Mini):

I have tracked down the cause of this: there is one code path in
ginFindParents() that doesn't take the function's own advice to
not release pin on the index's root page.  The attached seems to
fix it.  AFAICS the bug goes clear back to the origin of GIN.

> However, it seems like there might be more than one bug.  My first
> attempt died like this after a few minutes:
> TRAP: failed Assert("ref != NULL"), File: "bufmgr.c", Line: 2447, PID: 7177
> ...
> That was while running a build of commit 9ba9c7074 from 25 October.
> After updating to current HEAD (8bfb231b4), I've not yet reproduced it.

Nothing to see there: that is the same bug.  The change in behavior is
accounted for by the intervening commit b8bff07da, which re-ordered
operations in bufmgr.c so that the lack of a resource manager entry
would be noticed before hitting this Assert.

I find it quite scary that, per the code coverage report,
ginFindParents() isn't reached at all during our regression tests.
And there are several other areas in ginbtree.c that aren't reached
either.  Even while running Jeff's test case, I can find no evidence
that the freestack == false path in ginFinishSplit() is ever reached.
There could be a pile of resource-mismanagement bugs similar to this
one in there, and we'd never know it.

Reaching this particular error requires a concurrent split of the
index's root page, so it's surely not that easy to trigger.  I wonder
if there's anything we could do to make such cases more testable.

			regards, tom lane


------- =_aaaaaaaaaa0
Content-Type: text/x-diff;
	name="fix-buffer-pinning-error-in-gin-page-split.patch";
	charset="us-ascii"
Content-ID: <1877333.1699843262.2@sss.pgh.pa.us>
Content-Description: fix-buffer-pinning-error-in-gin-page-split.patch
Content-Transfer-Encoding: quoted-printable

diff --git a/src/backend/access/gin/ginbtree.c b/src/backend/access/gin/gi=
nbtree.c
index fc694b40f1..2dd3853e70 100644
--- a/src/backend/access/gin/ginbtree.c
+++ b/src/backend/access/gin/ginbtree.c
@@ -272,7 +272,11 @@ ginFindParents(GinBtree btree, GinBtreeStack *stack)
 			blkno =3D GinPageGetOpaque(page)->rightlink;
 			if (blkno =3D=3D InvalidBlockNumber)
 			{
-				UnlockReleaseBuffer(buffer);
+				/* Do not release pin on the root buffer */
+				if (buffer !=3D root->buffer)
+					UnlockReleaseBuffer(buffer);
+				else
+					LockBuffer(buffer, GIN_UNLOCK);
 				break;
 			}
 			buffer =3D ginStepRight(buffer, btree->index, GIN_EXCLUSIVE);

------- =_aaaaaaaaaa0--