Date: Sat, 4 Jul 2026 08:19:46 +0000
From: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
To: Dilip Kumar <dilipbalaut@gmail.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>,
	"Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>,
	"Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>,
	"pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Subject: Re: Re-read subscription state after lock in AlterSubscription
Message-ID: <akjCIjHzb0qaSFl+@bdtpg>
References: 
 <TYRPR01MB121568CC10A0920C7A5ADCCC2F5F52@TYRPR01MB12156.jpnprd01.prod.outlook.com>
 <akZlreb754FkCFrv@bdtpg>
 <OS9PR01MB12149E944D7ECABF0C1DDCCB4F5F42@OS9PR01MB12149.jpnprd01.prod.outlook.com>
 <akc4NBxbNKeSvumI@bdtpg>
 <CAFiTN-tBC0kvymhKiq9hXdr-Cdsdezyyh-X5FCtzfBsAORGOaw@mail.gmail.com>
 <akdOLGFblqA3Yvd6@bdtpg>
 <TY4PR01MB17718E4AA1A80B59B1B6FBF2D94F42@TY4PR01MB17718.jpnprd01.prod.outlook.com>
 <CAA4eK1+OU57xnjQXC-z6qMT+bdPsHMzQVXLPMdBmhhq++zwu+g@mail.gmail.com>
 <akfXqSGeRpL+2Ypz@bdtpg>
 <CAFiTN-th6yN9W6QUu4oT05O2YU1bL7LiGbuBFQbrQmXG7LzS1A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: 
 <CAFiTN-th6yN9W6QUu4oT05O2YU1bL7LiGbuBFQbrQmXG7LzS1A@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/akjCIjHzb0qaSFl%2B%40bdtpg>
Precedence: bulk

Hi,

On Sat, Jul 04, 2026 at 01:30:08PM +0530, Dilip Kumar wrote:
> On Fri, Jul 3, 2026 at 9:09 PM Bertrand Drouvot
> <bertranddrouvot.pg@gmail.com> wrote:
> >
> > But while doing this and looking closely, I'm not sure AlterPublication() does
> > it right. Indeed, in theory, the OID could have been re-used too (between the
> > time we did the name resolution and the time we lock the publication). I think
> > what is needed is something similar to RangeVarGetRelidExtended(), means do the
> > name resolution, acl check (ownership) and lock acquisition, all in unison.
> >
> > That's what 0003 is trying to achieve for the subscription and 0004 for the
> > publication.
> >
> > What do you think?
> >
> 0003:
> 
> It looks like the implementation of DROP SUBSCRIPTION IF EXISTS has a
> concurrent drop race condition in DropSubscription(). Currently, if
> stmt->missing_ok is true, the initial lookup safely handles a missing
> subscription. However, once a subscription is found and the code
> enters the drop loop, a second internal lookup/refetch happens. If a
> concurrent transaction drops the subscription after our initial check
> but before this internal refetch, the code throws an error.
> Essentially, the loop completely ignores the missing_ok flag during
> the refetch phase.

Good catch, will fix, thanks! 

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com