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>
In-Reply-To: 
 <CAA4eK1LkRdbm5XA=qa82Rp_y4rnyJh8pypMWVqOezOZpzy=Oaw@mail.gmail.com>
From: Fujii Masao <masao.fujii@gmail.com>
Date: Thu, 11 Jun 2026 22:19:33 +0900
Message-ID: 
 <CAHGQGwG_3ff4HciHtTZ_uMvbJgSDWsz4Yawj_zQpDG6Yj=Mjng@mail.gmail.com>
Subject: Re: Fix race in ReplicationSlotRelease for ephemeral slots
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>,
 Xuneng Zhou <xunengzhou@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/CAHGQGwG_3ff4HciHtTZ_uMvbJgSDWsz4Yawj_zQpDG6Yj%3DMjng%40mail.gmail.com>
Precedence: bulk

On Thu, Jun 11, 2026 at 8:18=E2=80=AFPM Amit Kapila <amit.kapila16@gmail.co=
m> wrote:
> 1. Stale name read in local_sync_slot_required(): The reused cell
> holds a different name. local_sync_slot_required() might return false
> (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 was
actually dropped?


> 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 sy=
nced
> =3D false, skip the drop, and unlock OID_B at line 579. Since no drop
> occurred, the cell is still the same non-synced slot, so the lock and
> 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 on
OID_B?

Regards,

--=20
Fujii Masao