On Wed, May 27, 2026 at 8:50 PM Zhijie Hou (Fujitsu)
<houzj.fnst@fujitsu.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
