MIME-Version: 1.0
References: 
 <TY4PR01MB177184FF9EE916F577E1F554194082@TY4PR01MB17718.jpnprd01.prod.outlook.com>
 <CAFC+b6o-hD5VxVLZQovmHSYykF8Qzq3eiuBU-U1F_yR9-y6P_w@mail.gmail.com>
 <TY4PR01MB177180A7CE60BCDF286B1C6F594172@TY4PR01MB17718.jpnprd01.prod.outlook.com>
 <CABPTF7VyH1-W2xnDspECDEzFGQj=WTFpZBCqKfM11OAZa6gQHQ@mail.gmail.com>
 <CAHGQGwE+2WSqiAYgNJRkf_twdB+uRGozjjGhUn76vUKZ8dzbSA@mail.gmail.com>
 <CABPTF7VeA8szPv7LYDVY9_7LftV-HM8NFVQR2natPKmr73JW+A@mail.gmail.com>
 <TY4PR01MB1771887D33612C5A45F7E9CDF941E2@TY4PR01MB17718.jpnprd01.prod.outlook.com>
 <CAA4eK1LqFBKCkX2eoX3iQPxJJnzWTaCpdh9zNotxuoG8BgjdtA@mail.gmail.com>
 <CAA4eK1LkRdbm5XA=qa82Rp_y4rnyJh8pypMWVqOezOZpzy=Oaw@mail.gmail.com>
 <CAHGQGwG_3ff4HciHtTZ_uMvbJgSDWsz4Yawj_zQpDG6Yj=Mjng@mail.gmail.com>
 <CABPTF7WBh_mKi60EYLiueaZ_cdJvnrOrpSt3hQkuZ_uY4w5duA@mail.gmail.com>
 <CAA4eK1LJ9=BJU2oK5aFCfvW=w2muSXNHOPM18wHXHLkRzYxhTQ@mail.gmail.com>
 <CAHGQGwGGyEDL3dh7uJ6qPsGvnq4QK_R8+U=12CaprnzwrwaLGA@mail.gmail.com>
 <CABPTF7UCqndPh8jucFtWBpFMoA2oQkSObQGXVVQNVGMZ1q-DCg@mail.gmail.com>
 <CAA4eK1KT-FMjXfFdg98qq_04PNnW6T1G-SUNU9dUtn4AC5g86A@mail.gmail.com>
 <CABPTF7VxwhYAAFg+71jOg_MQLcJaPfPu40ADC8imyXwr-H967w@mail.gmail.com>
 <CAA4eK1JBBcS9R3m8nR93E5P-WxRwRx=AM+STZrp9g1Ma13kfag@mail.gmail.com>
 <CABPTF7Um6sB-7WLg5OeBMD5DvWNkj3ZwACp5A69hgL3GUD2Ezg@mail.gmail.com>
In-Reply-To: 
 <CABPTF7Um6sB-7WLg5OeBMD5DvWNkj3ZwACp5A69hgL3GUD2Ezg@mail.gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
Date: Sat, 20 Jun 2026 15:12:42 +0530
Message-ID: 
 <CAA4eK1LG3gwpqidgvAGaTdz4fQRZWbRMM_nz1+2UHh-muXCWKQ@mail.gmail.com>
Subject: Re: Fix race in ReplicationSlotRelease for ephemeral slots
To: Xuneng Zhou <xunengzhou@gmail.com>
Cc: Fujii Masao <masao.fujii@gmail.com>,
 "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>,
	Srinath Reddy Sadipiralla <srinath2133@gmail.com>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAA4eK1LG3gwpqidgvAGaTdz4fQRZWbRMM_nz1%2B2UHh-muXCWKQ%40mail.gmail.com>
Precedence: bulk

On Sat, Jun 20, 2026 at 12:11=E2=80=AFPM Xuneng Zhou <xunengzhou@gmail.com>=
 wrote:
>
> On Fri, Jun 19, 2026 at 8:08=E2=80=AFPM Amit Kapila <amit.kapila16@gmail.=
com> wrote:
> >
> > On Thu, Jun 18, 2026 at 2:06=E2=80=AFPM Xuneng Zhou <xunengzhou@gmail.c=
om> wrote:
> > >
> > > OK, how about elaborate it a bit like this:
> > >
> > > /*
> > >  * In the small window between getting the slot to drop and
> > >  * locking the database, there is a possibility of a parallel
> > >  * database drop by the startup process and the creation of a new
> > >  * slot by the user. This new user-created slot may end up using
> > >  * the same shared memory as that of 'local_slot'.
> > >  *
> > >  * If that happens, local_slot now describes the replacement slot:
> > >  * local_sync_slot_required() may have made its drop decision using
> > >  * the replacement slot's name or invalidation state, and slot_databa=
se
> > >  * may refer to the replacement slot's database. Thus check if
> > >  * local_slot is still a synced slot before performing the actual dro=
p.
> > >  * This does not prove it is the original slot, but it prevents dropp=
ing
> > >  * an ordinary user-created replacement slot, and the copied database=
 OID
> > >  * keeps lock/unlock symmetric. The remaining risk is limited to this
> > >  * cleanup cycle, such as briefly holding an unrelated database lock,=
 and
> > >  * is acceptable here because this race is rare.
> > >  */
> > >
> >
> > Okay inspired from your and Fujii-san's version, here is a third versio=
n:
> > /*
> >  * In the small window between getting the slot to drop and
> >  * locking the database, there is a possibility of a parallel
> >  * database drop by the startup process and the creation of a new
> >  * slot by the user. This new user-created slot may end up using
> >  * the same shared memory as that of 'local_slot'.
> >  *
> >  * Because local_slot still points to a reusable slot-array entry,
> >  * its fields (name, database OID, invalidation state) may already
> >  * describe such a replacement slot by the time we reach here. That
> >  * means the drop decision made by local_sync_slot_required() above
> >  * could have been based on the replacement slot's data, and
> >  * slot_database could refer to an unrelated database. The recheck
> >  * below keeps us from actually dropping a user-created replacement
> >  * slot; the residual risk is confined to this cycle (for example,
> >  * briefly locking an unrelated database) and is acceptable because
> >  * the race is rare and non-fatal.
> >  */
> >
> > Thoughts?
>
> LGTM. It looks well-articulated.
>

Thanks, I'll push this as soon as the PG20 branch opens.

--=20
With Regards,
Amit Kapila.