Thread

Re: Proposal: Conflict log history table for Logical Replication

Dilip Kumar <dilipbalaut@gmail.com> — 2026-05-04T05:51:53Z

On Mon, May 4, 2026 at 11:18 AM shveta malik <shveta.malik@gmail.com> wrote:
>
> 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.
>
> Dilip, instead of granting permission (or removing restrictions) on
> the pg_conflict schema to all users, is there a way to grant USAGE on
> the schema only to the subscription owner when the conflict log table
> is created and when the owner is altered for the subscription? I think
> it should resolve the problem in a better way. Thoughts?  Let me know
> if I am missing something.

Yeah I thought about that but when you create a subscription, you
connected using the subscription owner user, who doesn't have the
necessary permission to GRANT usage on pg_conflict schema.

-- 
Regards,
Dilip Kumar
Google