On Fri, May 1, 2026 at 7:16 PM Dilip Kumar <dilipbalaut@gmail.com> 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
