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>
 <CABPTF7VdFwiROsch4T7VbOCqQYpRbh==gAZPM6tJeff5Ou80Qw@mail.gmail.com>
 <TY4PR01MB17718F4D0C5C8EB96A303C2E594E52@TY4PR01MB17718.jpnprd01.prod.outlook.com>
 <CAA4eK1K7e1Y2iYkmRZ5CCh0pZOTMUShKDj0nP4nY3Wdcypt7oQ@mail.gmail.com>
 <TY4PR01MB177185B82B7BD0A20028E4CED94E52@TY4PR01MB17718.jpnprd01.prod.outlook.com>
In-Reply-To: 
 <TY4PR01MB177185B82B7BD0A20028E4CED94E52@TY4PR01MB17718.jpnprd01.prod.outlook.com>
From: Xuneng Zhou <xunengzhou@gmail.com>
Date: Wed, 17 Jun 2026 15:08:40 +0800
Message-ID: 
 <CABPTF7Vyt13sex0VCQaVSw-4Hiru5=nL9S-9GkfRDQAMwUFe8A@mail.gmail.com>
Subject: Re: Fix race in ReplicationSlotRelease for ephemeral slots
To: "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>,
 Fujii Masao <masao.fujii@gmail.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/CABPTF7Vyt13sex0VCQaVSw-4Hiru5%3DnL9S-9GkfRDQAMwUFe8A%40mail.gmail.com>
Precedence: bulk

On Tue, Jun 16, 2026 at 6:32=E2=80=AFPM Zhijie Hou (Fujitsu)
<houzj.fnst@fujitsu.com> wrote:
>
> On Tuesday, June 16, 2026 5:36 PM Amit Kapila <amit.kapila16@gmail.com> w=
rote:
> >
> > On Tue, Jun 16, 2026 at 2:24=E2=80=AFPM Zhijie Hou (Fujitsu) <houzj.fns=
t@fujitsu.com>
> > wrote:
> > >
> > >
> > > I have one minor comment for the 0001 patch.
> > >
> > > +                       NameData        slot_name =3D {0};
> > > ...
> > >                         SpinLockAcquire(&local_slot->mutex);
> > >                         synced_slot =3D local_slot->in_use &&
> > > local_slot->data.synced;
> > > +                       if (synced_slot)
> > > +                               slot_name =3D local_slot->data.name;
> > >                         SpinLockRelease(&local_slot->mutex);
> > >
> > > We can defer assigning slot_name until after we pass the existing
> > > (synced_slot) check. Since it's a synced slot, no other process can
> > > change it at that point, and we can also skip initializing slot_name.
> > > (Please refer to the attached patch for suggested changes)
> > >

This seems ok to me. The only risk is that people who don't know the
assumption might think this getter is unsafe.

> > + if (dropped)
> > + ereport(LOG,
> > + errmsg("dropped replication slot \"%s\" of database with OID %u",
> > +    NameStr(slot_name),
> > +    slot_database));
> >
> > Can we avoid the if (dropped) check by placing this LOG message immedia=
tely
> > after dropping the slot under synced slot check?
>
> I think we can do that.

+1. Placing the log message within the lock window looks OK to me
since the cost is small.

> I'm attaching the new patches for all supported
> branches, incorporating both my and Amit's comments. I hope this helps mo=
ve the
> fix forward.
>
> I also confirmed that the fix works on all supported branches.

Thanks for your preparation for patches and confirmation of them!

--=20
Regards,
Xuneng Zhou
HighGo Software Co., Ltd.