Horton

Re: Bug with GIN index over JSONB data: "ERROR: buffer 10112 is not owned by resource owner"

Tom Lane <tgl@sss.pgh.pa.us>

View thread
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jeff Janes <jeff.janes@gmail.com>
Cc: pgsql-bugs <pgsql-bugs@lists.postgresql.org>
Date: 2023-11-10T04:31:02Z
Lists: pgsql-bugs

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Don't release index root page pin in ginFindParents().

  2. Make ResourceOwners more easily extensible.

  3. Don't install ldap_password_func in meson

  4. Fix some regression tests for d3d55ce57136

Attachments

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

pgbench: error: client 1 script 0 aborted in command 0 query 0: ERROR:  buffer pin 0x1cab is not owned by resource owner Portal
pgbench: error: Run was aborted; the above results are incomplete.

FTR, I used the attached not-so-ubuntu-specific script, and a
very vanilla assert-enabled build.

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
0   postgres                            0x0000000102caab74 ExceptionalCondition + 108
1   postgres                            0x0000000102b46490 UnpinBuffer + 528
2   postgres                            0x000000010282bae4 ginFinishSplit + 1700
3   postgres                            0x00000001028368ac ginEntryInsert + 904
4   postgres                            0x0000000102837194 gininsert + 472
5   postgres                            0x00000001029bf77c ExecInsertIndexTuples + 552
6   postgres                            0x00000001029ed0d4 ExecInsert + 1948
7   postgres                            0x00000001029ebbfc ExecModifyTable + 1252
8   postgres                            0x00000001029c0dc4 standard_ExecutorRun + 268
9   postgres                            0x0000000102b86450 ProcessQuery + 160
10  postgres                            0x0000000102b85afc PortalRunMulti + 396
11  postgres                            0x0000000102b85478 PortalRun + 476
12  postgres                            0x0000000102b8453c exec_simple_query + 1312
13  postgres                            0x0000000102b82250 PostgresMain + 3452

That was while running a build of commit 9ba9c7074 from 25 October.
After updating to current HEAD (8bfb231b4), I've not yet reproduced it.
But I suspect that's just bad luck, because this doesn't look like
anything we fixed in the last couple weeks.

			regards, tom lane