Re: Fix race in ReplicationSlotRelease for ephemeral slots - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: Fix race in ReplicationSlotRelease for ephemeral slots
Date
Msg-id CAHGQGwG_3ff4HciHtTZ_uMvbJgSDWsz4Yawj_zQpDG6Yj=Mjng@mail.gmail.com
Whole thread
In response to Re: Fix race in ReplicationSlotRelease for ephemeral slots  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Fix race in ReplicationSlotRelease for ephemeral slots
List pgsql-hackers
On Thu, Jun 11, 2026 at 8:18 PM Amit Kapila <amit.kapila16@gmail.com> 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?


> 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?

Regards,

--
Fujii Masao



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Heads Up: cirrus-ci is shutting down June 1st
Next
From: Mark Wong
Date:
Subject: Re: updates for handling optional argument in system functions