Re: Non-superuser subscription owners - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: Non-superuser subscription owners
Date
Msg-id CAA4eK1KXug_ftiQpPMgYGZdNoqLF34fZcbgLHhpzzTTppQgTvQ@mail.gmail.com
Whole thread Raw
In response to Re: Non-superuser subscription owners  (Amit Kapila <amit.kapila16@gmail.com>)
Responses RE: Non-superuser subscription owners
List pgsql-hackers
On Tue, Jun 13, 2023 at 2:25 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Fri, May 12, 2023 at 3:28 PM Zhijie Hou (Fujitsu)
> <houzj.fnst@fujitsu.com> wrote:
> >
> >
> > I can reproduce this via gdb following similar steps in [1].
> >
> > I think we need to move this call into a transaction as well and here is an attempt
> > to do that.
> >
>
> I am able to reproduce this issue following the steps mentioned by you
> and the proposed patch to fix the issue looks good to me.
>

Today, again looking at the patch, it seems to me that it would be
better if we can fix this without starting a new transaction. Won't it
be better if we move this syscall to a place where we are fetching
relstate (GetSubscriptionRelState()) a few lines above? I understand
by doing that in some cases like when copy_data = false, we may do
this syscall unnecessarily but OTOH, starting a new transaction just
for a syscall (superuser_arg()) also doesn't seem like a good idea to
me.

--
With Regards,
Amit Kapila.



pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: Avoid unncessary always true test (src/backend/storage/buffer/bufmgr.c)
Next
From: Peter Geoghegan
Date:
Subject: Re: Inconsistent results with libc sorting on Windows