public inbox for [email protected]
help / color / mirror / Atom feedFrom: Amit Kapila <[email protected]>
To: Xuneng Zhou <[email protected]>
Cc: Fujii Masao <[email protected]>
Cc: Zhijie Hou (Fujitsu) <[email protected]>
Cc: Srinath Reddy Sadipiralla <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: Fix race in ReplicationSlotRelease for ephemeral slots
Date: Fri, 12 Jun 2026 16:24:11 +0530
Message-ID: <CAA4eK1LJ9=BJU2oK5aFCfvW=w2muSXNHOPM18wHXHLkRzYxhTQ@mail.gmail.com> (raw)
In-Reply-To: <CABPTF7WBh_mKi60EYLiueaZ_cdJvnrOrpSt3hQkuZ_uY4w5duA@mail.gmail.com>
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>
On Fri, Jun 12, 2026 at 8:22 AM Xuneng Zhou <[email protected]> wrote:
>
> The issues look real to me and could be dealt with patch v1 partially.
>
> On Thu, Jun 11, 2026 at 9:19 PM Fujii Masao <[email protected]> wrote:
> >
> > On Thu, Jun 11, 2026 at 8:18 PM Amit Kapila <[email protected]> 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 = 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?
>
> 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–565 we see synced
> > > = 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 — 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?
>
> 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=false
> 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
> 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. We can push forward with 0001 and then do more
discussion for 0002, if required. I can take care of 0001 unless
Fujii-San wishes to take care of it?
--
With Regards,
Amit Kapila.
view thread (27+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Fix race in ReplicationSlotRelease for ephemeral slots
In-Reply-To: <CAA4eK1LJ9=BJU2oK5aFCfvW=w2muSXNHOPM18wHXHLkRzYxhTQ@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox