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

From shveta malik
Subject Re: Proposal: Conflict log history table for Logical Replication
Date
Msg-id CAJpy0uDZBKfB85Qp+KNE=oCg3NxiAyNE2jBJi=SMG4i0ujRq2Q@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 Mon, May 4, 2026 at 2:37 PM Dilip Kumar <dilipbalaut@gmail.com> wrote:
>
> On Mon, 4 May 2026 at 11:21 AM, Dilip Kumar <dilipbalaut@gmail.com> wrote:
>>
>> 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.
>
>
> After putting more thoughts I think we should be able to execute internal GRAN function which do not checks whether
theuser has permission to GRANT or not. 
>

I have been trying to find an existing code example that does
somethign similar, but could not find one. But if you think it is
feasible and found a way, then it is the reasonable solution here.

thanks
Shveta



pgsql-hackers by date:

Previous
From: Dilip Kumar
Date:
Subject: Re: Proposal: Conflict log history table for Logical Replication
Next
From: SATYANARAYANA NARLAPURAM
Date:
Subject: [Bug]Vacuum full silently NULL out fast default columns