Re: Fix race in ReplicationSlotRelease for ephemeral slots

On Wed, May 27, 2026 at 8:50 PM Zhijie Hou (Fujitsu)
<houzj(dot)fnst(at)fujitsu(dot)com> wrote:
>
> Hi,
>
> While testing the slot release logic, I noticed a bug in
> ReplicationSlotRelease() where it may access a replication slot array entry that
> has already been released by itself.
>
> The detail is: When releasing an ephemeral replication slot,
> ReplicationSlotRelease() first drops the slot via ReplicationSlotDropAcquired().
> After this point, the slot's shared memory slot array entry can be immediately
> reused by another backend creating a new slot.
>
> However, ReplicationSlotRelease() continued executing common cleanup code that
> still dereferenced the old slot pointer and updated shared memory fields such as
> effective_xmin. If the slot array entry had already been reallocated, these
> writes could inadvertently affect a different, unrelated slot.

Good catch!

> I am attaching a patch that avoids touching slot shared-memory state after
> dropping an ephemeral slot. Keep the post-release shared-memory updates only for
> non-ephemeral slots, where the slot remains valid after release.

Thanks for the patch! It looks good to me.
Barring any objections, I will commit it.

> I haven't attached a test for this fix, as the change is straightforward and the
> likelihood of encountering this bug is low, so it may not be worth adding test
> cycles for it.

+1

Regards,

--
Fujii Masao