Re: Proposal: Conflict log history table for Logical Replication - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Proposal: Conflict log history table for Logical Replication
Date
Msg-id CAA4eK1JvnfK_JnMyyxQH5cTkifQOg_PDZqhHorU8=u=QigWKzQ@mail.gmail.com
Whole thread
In response to Re: Proposal: Conflict log history table for Logical Replication  (Dilip Kumar <dilipbalaut@gmail.com>)
Responses Re: Proposal: Conflict log history table for Logical Replication
List 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.



pgsql-hackers by date:

Previous
From: Varik Matevosyan
Date:
Subject: [PATCH] contrib/xml2: guard against signed integer overflow in parse_params
Next
From: Ayush Tiwari
Date:
Subject: Re: Enforce INSERT RLS checks for FOR PORTION OF leftovers?