Re: Proposal: Conflict log history table for Logical Replication
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: Dilip Kumar <dilipbalaut@gmail.com>
Cc: shveta malik <shveta.malik@gmail.com>, vignesh C <vignesh21@gmail.com>, Nisha Moond <nisha.moond412@gmail.com>, Peter Smith <smithpb2250@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-05-04T11:28:53Z
Lists: pgsql-hackers
On Sat, May 2, 2026 at 2:40 PM Dilip Kumar <dilipbalaut@gmail.com> wrote: > > 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. > How about if we grant usage privilege on pg_conflict schema to pg_create_subscription role and then allow only select, delete, truncate to table_owners on tables in pg_conflict schema? Internally the apply_worker can still make inserts to clt table in pg_conflict schema similar to what we do for toast tables. -- With Regards, Amit Kapila.