Thread
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Remove GLOBALTABLESPACE_OID assert for locked buffers.
- 4a4ee0c2c1e5 18.0 landed
-
BUG #18912: TRAP: failed Assert("tag.spcOid != GLOBALTABLESPACE_OID"), File: "bufmgr.c", Line: 4165, PID: 2115
PG Bug reporting form <noreply@postgresql.org> — 2025-05-05T22:01:15Z
The following bug has been logged on the website: Bug reference: 18912 Logged by: Adam Guo Email address: adamguo@amazon.com PostgreSQL version: Unsupported/Unknown Operating system: Amazon Linux 2 Description: Hi team, I noticed an assert failure in PG18beta1. I can reproduce it by running the following: ``` CREATE USER myuser; REINDEX SCHEMA pg_catalog; SET SESSION AUTHORIZATION myuser; GRANT ALTER SYSTEM ON PARAMETER log_filename TO myuser; GRANT ALTER SYSTEM ON PARAMETER log_filename TO myuser WITH GRANT OPTION; ``` From what I can tell, all of these statements are necessary to reproduce the error. On the last one, the backend aborts at buffer/bufmgr.c:4165 [1]. This assert was introduced in f4ece891 [2]. Seems like something is holding onto an LW_EXCLUSIVE lock on a system catalog? According to gdb, the relation in question is not a system catalog but does live in the pg_global tablespace. I can't find it in pg_class. ``` (gdb) up 3 #3 0x00000000009e1f48 in AssertNotCatalogBufferLock (lock=0x7f8ab5782c30, mode=LW_EXCLUSIVE, unused_context=0x0) at bufmgr.c:4165 4165 Assert(tag.spcOid != GLOBALTABLESPACE_OID); (gdb) p tag.spcOid $1 = 1664 (gdb) p relid $2 = 16526 ``` Regards, Adam Guo [1] https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/storage/buffer/bufmgr.c;hb=HEAD#l4165 [2] https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=f4ece891fc2f -
Re: BUG #18912: TRAP: failed Assert("tag.spcOid != GLOBALTABLESPACE_OID"), File: "bufmgr.c", Line: 4165, PID: 2115
Noah Misch <noah@leadboat.com> — 2025-05-06T00:31:01Z
On Mon, May 05, 2025 at 10:01:15PM +0000, PG Bug reporting form wrote: > ``` > CREATE USER myuser; > REINDEX SCHEMA pg_catalog; > SET SESSION AUTHORIZATION myuser; > GRANT ALTER SYSTEM ON PARAMETER log_filename TO myuser; > GRANT ALTER SYSTEM ON PARAMETER log_filename TO myuser WITH GRANT OPTION; > ``` > From what I can tell, all of these statements are necessary to reproduce the > error. On the last one, the backend aborts at buffer/bufmgr.c:4165 [1]. > This > assert was introduced in f4ece891 [2]. Seems like something is holding onto > an > LW_EXCLUSIVE lock on a system catalog? > According to gdb, the relation in question is not a system catalog but does > live > in the pg_global tablespace. I can't find it in pg_class. > ``` > (gdb) up 3 > #3 0x00000000009e1f48 in AssertNotCatalogBufferLock (lock=0x7f8ab5782c30, > mode=LW_EXCLUSIVE, > unused_context=0x0) at bufmgr.c:4165 > 4165 Assert(tag.spcOid != GLOBALTABLESPACE_OID); > (gdb) p tag.spcOid > $1 = 1664 > (gdb) p relid > $2 = 16526 > ``` Thanks for the report. On my system, it's pg_parameter_acl_parname_index: [local] test=*# select pg_filenode_relation(1664, '16529'); pg_filenode_relation ──────────────────────────────── pg_parameter_acl_parname_index (1 row) That's an IsCatalogTextUniqueIndexOid() index, but the REINDEX makes AssertNotCatalogBufferLock() unable to detect it as one. Hence, I think I'll be removing the assert you reached: --- a/src/backend/storage/buffer/bufmgr.c +++ b/src/backend/storage/buffer/bufmgr.c @@ -4160,10 +4160,8 @@ AssertNotCatalogBufferLock(LWLock *lock, LWLockMode mode, if (IsCatalogTextUniqueIndexOid(relid)) /* see comments at the callee */ return; Assert(!IsCatalogRelationOid(relid)); - /* Shared rels are always catalogs: detect even after VACUUM FULL. */ - Assert(tag.spcOid != GLOBALTABLESPACE_OID); } It's true that shared rels are always catalogs. However, without a way to judge IsCatalogTextUniqueIndexOid(), we can't assert-fail. > [1] > https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/backend/storage/buffer/bufmgr.c;hb=HEAD#l4165 > [2] > https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=f4ece891fc2f -
Re: BUG #18912: TRAP: failed Assert("tag.spcOid != GLOBALTABLESPACE_OID"), File: "bufmgr.c", Line: 4165, PID: 2115
Masahiko Sawada <sawada.mshk@gmail.com> — 2025-05-06T04:52:51Z
On Mon, May 5, 2025 at 5:31 PM Noah Misch <noah@leadboat.com> wrote: > > On Mon, May 05, 2025 at 10:01:15PM +0000, PG Bug reporting form wrote: > > ``` > > CREATE USER myuser; > > REINDEX SCHEMA pg_catalog; > > SET SESSION AUTHORIZATION myuser; > > GRANT ALTER SYSTEM ON PARAMETER log_filename TO myuser; > > GRANT ALTER SYSTEM ON PARAMETER log_filename TO myuser WITH GRANT OPTION; > > ``` > > From what I can tell, all of these statements are necessary to reproduce the > > error. On the last one, the backend aborts at buffer/bufmgr.c:4165 [1]. > > This > > assert was introduced in f4ece891 [2]. Seems like something is holding onto > > an > > LW_EXCLUSIVE lock on a system catalog? > > According to gdb, the relation in question is not a system catalog but does > > live > > in the pg_global tablespace. I can't find it in pg_class. > > ``` > > (gdb) up 3 > > #3 0x00000000009e1f48 in AssertNotCatalogBufferLock (lock=0x7f8ab5782c30, > > mode=LW_EXCLUSIVE, > > unused_context=0x0) at bufmgr.c:4165 > > 4165 Assert(tag.spcOid != GLOBALTABLESPACE_OID); > > (gdb) p tag.spcOid > > $1 = 1664 > > (gdb) p relid > > $2 = 16526 > > ``` > > Thanks for the report. On my system, it's pg_parameter_acl_parname_index: > > [local] test=*# select pg_filenode_relation(1664, '16529'); > pg_filenode_relation > ──────────────────────────────── > pg_parameter_acl_parname_index > (1 row) > > That's an IsCatalogTextUniqueIndexOid() index, but the REINDEX makes > AssertNotCatalogBufferLock() unable to detect it as one. Hence, I think I'll > be removing the assert you reached: > > --- a/src/backend/storage/buffer/bufmgr.c > +++ b/src/backend/storage/buffer/bufmgr.c > @@ -4160,10 +4160,8 @@ AssertNotCatalogBufferLock(LWLock *lock, LWLockMode mode, > if (IsCatalogTextUniqueIndexOid(relid)) /* see comments at the callee */ > return; > > Assert(!IsCatalogRelationOid(relid)); > - /* Shared rels are always catalogs: detect even after VACUUM FULL. */ > - Assert(tag.spcOid != GLOBALTABLESPACE_OID); > } +1. Seems reasonable approach. Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com