Thread

Re: Proposal: Conflict log history table for Logical Replication

Dilip Kumar <dilipbalaut@gmail.com> — 2026-05-02T09:10:02Z

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