RE: Re-read subscription state after lock in AlterSubscription - Mailing list pgsql-hackers

From Zhijie Hou (Fujitsu)
Subject RE: Re-read subscription state after lock in AlterSubscription
Date
Msg-id TY4PR01MB177181942280B78B500AD68F294F42@TY4PR01MB17718.jpnprd01.prod.outlook.com
Whole thread
In response to Re: Re-read subscription state after lock in AlterSubscription  (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>)
List pgsql-hackers
On Friday, July 3, 2026 5:03 PM Bertrand Drouvot <bertranddrouvot.pg@gmail.com> wrote:
> On Fri, Jul 03, 2026 at 08:08:13AM +0000, Zhijie Hou (Fujitsu) wrote:
> > On Friday, July 3, 2026 1:53 PM Bertrand Drouvot
> <bertranddrouvot.pg@gmail.com> wrote:
> > >
> > > That said, what about also fixing DropSubscription() like in the 0002
> attached?
> > > (that would also produce those elog() messages in case of concurrent
> > > DROP or ALTER).
> >
> > For the patch, I'm not sure if we must repeat the checks twice.
>
> Thanks for looking at it!
>
> > Could we
> > simply move the original checks to after we take the lock? At least,
> > the
> > GetSubscription() call and the password check can be moved there and
> > old codes can be deleted.
>
> I'm not sure which checks you refer to. The ones that are keep before the lock
> acquisition are because we don't want to lock an object we don't have
> privileges on (see remark 3 in [1]).

I was referring to the password_required check and the GetSubscription() call.

I think failing the password_required check does not necessarily mean we do not
have the permission to lock the subscription, It seems to me we only need to
disallow changing the subscription data in this case. In
DropSubscription, we take a lock on the subscription regardless of
password_required.

Best Regards,
Hou zj



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: implement CAST(expr AS type FORMAT 'template')
Next
From: Alexandre Felipe
Date:
Subject: Re: SLOPE - Planner optimizations on monotonic expressions.