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>
In-Reply-To: 
 <CAA4eK1LJ9=BJU2oK5aFCfvW=w2muSXNHOPM18wHXHLkRzYxhTQ@mail.gmail.com>
From: Xuneng Zhou <xunengzhou@gmail.com>
Date: Tue, 16 Jun 2026 13:29:35 +0800
Message-ID: 
 <CABPTF7VdFwiROsch4T7VbOCqQYpRbh==gAZPM6tJeff5Ou80Qw@mail.gmail.com>
Subject: Re: Fix race in ReplicationSlotRelease for ephemeral slots
To: Amit Kapila <amit.kapila16@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/CABPTF7VdFwiROsch4T7VbOCqQYpRbh%3D%3DgAZPM6tJeff5Ou80Qw%40mail.gmail.com>
Precedence: bulk

On Fri, Jun 12, 2026 at 6:54=E2=80=AFPM Amit Kapila <amit.kapila16@gmail.co=
m> wrote:
>
> On Fri, Jun 12, 2026 at 8:22=E2=80=AFAM Xuneng Zhou <xunengzhou@gmail.com=
> wrote:
> >
> > The issues look real to me and could be dealt with patch v1 partially.
> >
> > On Thu, Jun 11, 2026 at 9:19=E2=80=AFPM Fujii Masao <masao.fujii@gmail.=
com> wrote:
> > >
> > > On Thu, Jun 11, 2026 at 8:18=E2=80=AFPM Amit Kapila <amit.kapila16@gm=
ail.com> wrote:
> > > > 1. Stale name read in local_sync_slot_required(): The reused cell
> > > > holds a different name. local_sync_slot_required() might return fal=
se
> > > > (drop needed). But then the in_use && synced spinlock check sees
> > > > synced =3D false and skips the actual drop. The wrong decision is
> > > > caught.
> > >
> > > Yes, we could skip the actual drop. But then wouldn't we still emit
> > > the log message "dropped replication slot ..." even though no slot wa=
s
> > > actually dropped?
> >
> > With v1, we won't emit the log message unless the log is factually
> > dropped. However it did not prevent the stale read in
> > local_sync_slot_required().
> >
> > > > 2. Wrong database OID read at line 551: The reused cell holds OID_B
> > > > from the new slot. We lock OID_B, then at lines 563=E2=80=93565 we =
see synced
> > > > =3D false, skip the drop, and unlock OID_B at line 579. Since no dr=
op
> > > > occurred, the cell is still the same non-synced slot, so the lock a=
nd
> > > > unlock see the same OID_B. Symmetric =E2=80=94 no lock leak.
> > >
> > > What happens if the slot for OID_B is dropped after we lock
> > > OID_B, and then a new slot for OID_C reuses the same array entry? In
> > > that case, wouldn't the later unlock read OID_C from
> > > local_slot->data.database even though the lock was originally taken o=
n
> > > OID_B?
> >
> > V1 stops doing the venerable second read of local_slot->data.database.
> > So if the copied value was already stale and points to OID_B, v1 is at
> > least symmetric:
> >
> > read OID_B once
> > lock OID_B
> > cell reused as OID_C
> > unlock OID_B
> >
> > But v1 seems not to fully  solve issue 1.
> >
> > It can still do this:
> >
> > cell already reused before slot_database is copied
> > v1 copies OID_B from replacement slot
> > locks OID_B
> > recheck sees synced=3Dfalse
> > skips drop
> > unlocks OID_B
> >
> > That is still a stale read and possibly a wasted/wrong database lock,
> > but it doesn't leak the lock, unlocks the wrong object, logs a false
> > drop, or drops the replacement slot.
> >
> > In an off-list chat with Zhijie, we kinda thought that holding the
> > lock of a wrong db for a brief time doesn't seem to harm a lot. The
> > concurrent dropping-db operation leads to this issue seems rare in
> > practice. He stated that the deletion of the slot seems unavoidable
> > because we have to acquire the database lock after releasing the
> > replication slot lock to avoid the deadlock with the startup/drop db
> > operation. Therefore, he prefered keeping the design simple and
> > avoiding the fatal issue over doing a broader refactoring work.
> >
>
> +1. I also think this change is not worth it.

I am also OK with the scope of change made by patch 1.

> > don't have a strong opinion on this. Still attaching the refactoring
> > patch to do some clean-up in case someone thinks it's worthwhile.
> >
>
> I feel even if there is an argument to do such a refactoring, it can
> be done separately.

Makes sense to me.

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