On Fri, May 1, 2026 at 7:16 PM Dilip Kumar <[email protected]> wrote: > > 4. pg_conflict is the catalog schema and as Nisha reported, > non-superusers aren't allowed to access the objects within it. Because > of this, SELECT, DELETE, and TRUNCATE are disallowed even for the > subscription owner if that owner is a non-superuser. I am working on > the fix.
While analyzing this, I realized that the schema ACL check happens very early in analyze phase [1]. I'm not sure if we can bypass the subscription owner from this check at that stage without implementing a hacky solution. Another option is to remove restrictions from the pg_conflict schema for all users and keep only table-level restrictions within that schema. I am exploring how to implement this. #1 0x0000561b547713fe in aclcheck_error (aclerr=ACLCHECK_NO_PRIV, objtype=OBJECT_SCHEMA, objectname=0x561b8299a4d0 "pg_conflict") at aclchk.c:2813 #2 0x0000561b54790fe7 in LookupExplicitNamespace (nspname=0x561b8299a4d0 "pg_conflict", missing_ok=true) at namespace.c:3481 #3 0x0000561b5478ca48 in RangeVarGetRelidExtended (relation=0x561b8299a590, lockmode=1, flags=1, callback=0x0, callback_arg=0x0) at namespace.c:531 #4 0x0000561b54645779 in relation_openrv_extended (relation=0x561b8299a590, lockmode=1, missing_ok=true) at relation.c:186 #5 0x0000561b5470e7ba in table_openrv_extended (relation=0x561b8299a590, lockmode=1, missing_ok=true) at table.c:108 #6 0x0000561b548383a2 in parserOpenTable (pstate=0x561b8299a7e0, relation=0x561b8299a590, lockmode=1) at parse_relation.c:1433 -- Regards, Dilip Kumar Google
