On Mon, May 4, 2026 at 2:43 PM shveta malik <[email protected]> wrote: > > On Mon, May 4, 2026 at 2:37 PM Dilip Kumar <[email protected]> wrote: > > > > On Mon, 4 May 2026 at 11:21 AM, Dilip Kumar <[email protected]> wrote: > >> > >> On Mon, May 4, 2026 at 11:18 AM shveta malik <[email protected]> > >> wrote: > >> > > >> > On Sat, May 2, 2026 at 2:40 PM Dilip Kumar <[email protected]> wrote: > >> > > > >> > > On Fri, May 1, 2026 at 7:16 PM Dilip Kumar <[email protected]> > >> > > 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 the user 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.
Even I am not sure but I am going to experiment with this by calling ExecGrantStmt_oids() while creating the subscription to see if we can come up with something reasonable. -- Regards, Dilip Kumar Google
