MIME-Version: 1.0
References: 
 <TY4PR01MB177184FF9EE916F577E1F554194082@TY4PR01MB17718.jpnprd01.prod.outlook.com>
In-Reply-To: 
 <TY4PR01MB177184FF9EE916F577E1F554194082@TY4PR01MB17718.jpnprd01.prod.outlook.com>
From: Srinath Reddy Sadipiralla <srinath2133@gmail.com>
Date: Fri, 29 May 2026 22:14:10 +0530
Message-ID: 
 <CAFC+b6o-hD5VxVLZQovmHSYykF8Qzq3eiuBU-U1F_yR9-y6P_w@mail.gmail.com>
Subject: Re: Fix race in ReplicationSlotRelease for ephemeral slots
To: "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Content-Type: multipart/mixed; boundary="0000000000008797e70652f78ebb"
Archived-At: 
 <https://www.postgresql.org/message-id/CAFC%2Bb6o-hD5VxVLZQovmHSYykF8Qzq3eiuBU-U1F_yR9-y6P_w%40mail.gmail.com>
Precedence: bulk

--0000000000008797e70652f78ebb
Content-Type: multipart/alternative; boundary="0000000000008797e60652f78eb9"

--0000000000008797e60652f78eb9
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Wed, May 27, 2026 at 5:20=E2=80=AFPM Zhijie Hou (Fujitsu) <houzj.fnst@fu=
jitsu.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, the=
se
> writes could inadvertently affect a different, unrelated slot.
>
> I am attaching a patch that avoids touching slot shared-memory state afte=
r
> dropping an ephemeral slot. Keep the post-release shared-memory updates
> only for
> non-ephemeral slots, where the slot remains valid after release.
>
> To reproduce, we can use the following steps:
>
> 1. Attach gdb to the backend and set a breakpoint in
> ReplicationSlotRelease()
>    right after ReplicationSlotDropAcquired() is called.
> 2. Create an ephemeral slot in the above backend with an invalid output
> plugin:
>    SELECT pg_create_logical_replication_slot('test_slot_dropped',
> 'pgoutput2', false, false, true);
> 3. Once the breakpoint is hit, start another backend and create a new slo=
t
>    named 'test_slot_created'.
> 4. Release the breakpoint and allow the first backend to continue. At thi=
s
>    point, you will see it updating the new slot 'test_slot_created' ->
> active_proc
>    (and effective_xmin, if a snapshot is being exported) to invalid value=
s.
> 5. Start a third backend and attempt to acquire the same slot
>    'test_slot_created' ? this should not be possible under normal
> circumstances,
>    but the bug allows it.
>

patch LGTM.


>
> 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. However, if others feel differently, I'm OK to add one.
>

+1 for a test. The fix is just an else, so a future refactor could change
it and silently
reintroduce the corruption, since it scribbles on an unrelated reused slot,
nothing
would catch it. Injection points make it deterministic; I've attached a
diff patch that adds
a test that fails without the fix and passes with it.


--=20
Thanks,
Srinath Reddy Sadipiralla
EDB: https://www.enterprisedb.com/

--0000000000008797e60652f78eb9
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hi,</div><br><div class=3D"gmail_quote gm=
ail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, May 27, =
2026 at 5:20=E2=80=AFPM Zhijie Hou (Fujitsu) &lt;<a href=3D"mailto:houzj.fn=
st@fujitsu.com">houzj.fnst@fujitsu.com</a>&gt; wrote:<br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
While testing the slot release logic, I noticed a bug in<br>
ReplicationSlotRelease() where it may access a replication slot array entry=
 that<br>
has already been released by itself.<br>
<br>
The detail is: When releasing an ephemeral replication slot,<br>
ReplicationSlotRelease() first drops the slot via ReplicationSlotDropAcquir=
ed().<br>
After this point, the slot&#39;s shared memory slot array entry can be imme=
diately<br>
reused by another backend creating a new slot.<br>
<br>
However, ReplicationSlotRelease() continued executing common cleanup code t=
hat<br>
still dereferenced the old slot pointer and updated shared memory fields su=
ch as<br>
effective_xmin. If the slot array entry had already been reallocated, these=
<br>
writes could inadvertently affect a different, unrelated slot.<br>
<br>
I am attaching a patch that avoids touching slot shared-memory state after<=
br>
dropping an ephemeral slot. Keep the post-release shared-memory updates onl=
y for<br>
non-ephemeral slots, where the slot remains valid after release.<br>
<br>
To reproduce, we can use the following steps:<br>
<br>
1. Attach gdb to the backend and set a breakpoint in ReplicationSlotRelease=
()<br>
=C2=A0 =C2=A0right after ReplicationSlotDropAcquired() is called.<br>
2. Create an ephemeral slot in the above backend with an invalid output plu=
gin:<br>
=C2=A0 =C2=A0SELECT pg_create_logical_replication_slot(&#39;test_slot_dropp=
ed&#39;, &#39;pgoutput2&#39;, false, false, true);<br>
3. Once the breakpoint is hit, start another backend and create a new slot<=
br>
=C2=A0 =C2=A0named &#39;test_slot_created&#39;.<br>
4. Release the breakpoint and allow the first backend to continue. At this<=
br>
=C2=A0 =C2=A0point, you will see it updating the new slot &#39;test_slot_cr=
eated&#39; -&gt; active_proc<br>
=C2=A0 =C2=A0(and effective_xmin, if a snapshot is being exported) to inval=
id values.<br>
5. Start a third backend and attempt to acquire the same slot<br>
=C2=A0 =C2=A0&#39;test_slot_created&#39; ? this should not be possible unde=
r normal circumstances,<br>
=C2=A0 =C2=A0but the bug allows it.<br></blockquote><div><br>patch LGTM.<br=
>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px =
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I haven&#39;t attached a test for this fix, as the change is straightforwar=
d and the<br>
likelihood of encountering this bug is low, so it may not be worth adding t=
est<br>
cycles for it. However, if others feel differently, I&#39;m OK to add one.<=
br></blockquote><div>=C2=A0</div><div>+1 for a test. The fix is just an els=
e, so a future refactor could change it and silently<br>reintroduce the cor=
ruption, since it scribbles on an unrelated reused slot, nothing<br>would c=
atch it. Injection points make it deterministic; I&#39;ve attached a diff p=
atch that adds<br>a test that fails without the fix and passes with it.<br>=
<br></div></div><div><br></div><span class=3D"gmail_signature_prefix">-- </=
span><br><div dir=3D"ltr" class=3D"gmail_signature"><div dir=3D"ltr"><span =
style=3D"color:rgb(34,34,34)">Thanks,</span><br style=3D"color:rgb(34,34,34=
)"><span style=3D"color:rgb(34,34,34)">Srinath Reddy Sadipiralla</span><br =
style=3D"color:rgb(34,34,34)"><span style=3D"color:rgb(34,34,34)">EDB:=C2=
=A0</span><a href=3D"https://www.enterprisedb.com/" style=3D"color:rgb(17,8=
5,204)" target=3D"_blank">https://www.enterprisedb.com/</a></div></div></di=
v>

--0000000000008797e60652f78eb9--

--0000000000008797e70652f78ebb
Content-Type: application/octet-stream; name="nocfbot-test.patch"
Content-Disposition: attachment; filename="nocfbot-test.patch"
Content-Transfer-Encoding: base64
Content-ID: <f_mpr5i3a60>
X-Attachment-Id: f_mpr5i3a60

ZGlmZiAtLWdpdCBhL3NyYy9iYWNrZW5kL3JlcGxpY2F0aW9uL3Nsb3QuYyBiL3NyYy9iYWNrZW5k
L3JlcGxpY2F0aW9uL3Nsb3QuYwppbmRleCBmMDEyZTk5YzlkNy4uYTkxMDgyZWZiOWMgMTAwNjQ0
Ci0tLSBhL3NyYy9iYWNrZW5kL3JlcGxpY2F0aW9uL3Nsb3QuYworKysgYi9zcmMvYmFja2VuZC9y
ZXBsaWNhdGlvbi9zbG90LmMKQEAgLTc4Nyw2ICs3ODcsMTQgQEAgUmVwbGljYXRpb25TbG90UmVs
ZWFzZSh2b2lkKQogCQkgKiBkZWNvZGluZyBiZSBkaXNhYmxlZC4KIAkJICovCiAJCVJlcGxpY2F0
aW9uU2xvdERyb3BBY3F1aXJlZChpc19sb2dpY2FsKTsKKworCQkvKgorCQkgKiBUaGUgc2xvdCdz
IGFycmF5IGVudHJ5IGlzIG5vdyBmcmVlIGFuZCBtYXkgYmUgcmV1c2VkIGJ5IGFub3RoZXIKKwkJ
ICogYmFja2VuZCBhdCBhbnkgbW9tZW50LiAgVGhpcyBpbmplY3Rpb24gcG9pbnQgbGV0cyB0ZXN0
cyBvcGVuIHRoYXQKKwkJICogd2luZG93IGRldGVybWluaXN0aWNhbGx5IGFuZCB2ZXJpZnkgd2Ug
bmV2ZXIgdG91Y2ggdGhlIChub3cgc3RhbGUpCisJCSAqIHNsb3QgcG9pbnRlciBhZnRlcndhcmRz
LgorCQkgKi8KKwkJSU5KRUNUSU9OX1BPSU5UKCJlcGhlbWVyYWwtc2xvdC1yZWxlYXNlLWFmdGVy
LWRyb3AiLCBOVUxMKTsKIAl9CiAKIAkvKgpkaWZmIC0tZ2l0IGEvc3JjL3Rlc3QvcmVjb3Zlcnkv
dC8wMDZfbG9naWNhbF9kZWNvZGluZy5wbCBiL3NyYy90ZXN0L3JlY292ZXJ5L3QvMDA2X2xvZ2lj
YWxfZGVjb2RpbmcucGwKaW5kZXggOTdkMTFmOThiNTkuLmZhNWEwMjIyZGNkIDEwMDY0NAotLS0g
YS9zcmMvdGVzdC9yZWNvdmVyeS90LzAwNl9sb2dpY2FsX2RlY29kaW5nLnBsCisrKyBiL3NyYy90
ZXN0L3JlY292ZXJ5L3QvMDA2X2xvZ2ljYWxfZGVjb2RpbmcucGwKQEAgLTI3NSw2ICsyNzUsODAg
QEAgaXMoICRub2RlX3ByaW1hcnktPnNhZmVfcHNxbCgKIAlxcShDaGVjayB0aGF0IHJlc2V0IHRp
bWVzdGFtcCBpcyBsYXRlciBhZnRlciByZXNldHRpbmcgc3RhdHMgZm9yIHNsb3QgJyRzdGF0c190
ZXN0X3Nsb3QxJyBhZ2Fpbi4pCiApOwogCisjIFJlZ3Jlc3Npb24gdGVzdCBmb3IgdGhlIHJhY2Ug
aW4gUmVwbGljYXRpb25TbG90UmVsZWFzZSgpIHdoZW4gcmVsZWFzaW5nIGFuCisjIGVwaGVtZXJh
bCBzbG90LiAgUmVsZWFzaW5nIGFuIGVwaGVtZXJhbCBzbG90IGZpcnN0IGRyb3BzIGl0IHZpYQor
IyBSZXBsaWNhdGlvblNsb3REcm9wQWNxdWlyZWQoKSwgd2hpY2ggZnJlZXMgdGhlIHNsb3QncyBh
cnJheSBlbnRyeSBmb3IgcmV1c2UuCisjIFJlcGxpY2F0aW9uU2xvdFJlbGVhc2UoKSBtdXN0IG5v
dCB0b3VjaCB0aGF0IChub3cgc3RhbGUpIHNsb3QgcG9pbnRlcgorIyBhZnRlcndhcmRzLCBvciBp
dCBjYW4gY29ycnVwdCBhbiB1bnJlbGF0ZWQgc2xvdCB0aGF0IGdyYWJiZWQgdGhlIGZyZWVkIGVu
dHJ5LgorIyBUaGlzIG5lZWRzIGFuIGluamVjdGlvbiBwb2ludCwgc28gaXQgb25seSBydW5zIG9u
IGJ1aWxkcyB0aGF0IHN1cHBvcnQgdGhlbS4KK1NLSVA6Cit7CisJc2tpcCAiSW5qZWN0aW9uIHBv
aW50cyBub3Qgc3VwcG9ydGVkIGJ5IHRoaXMgYnVpbGQiLCAyCisJICBpZiAkRU5We2VuYWJsZV9p
bmplY3Rpb25fcG9pbnRzfSBuZSAneWVzJzsKKwlza2lwICJFeHRlbnNpb24gaW5qZWN0aW9uX3Bv
aW50cyBub3QgaW5zdGFsbGVkIiwgMgorCSAgdW5sZXNzICRub2RlX3ByaW1hcnktPmNoZWNrX2V4
dGVuc2lvbignaW5qZWN0aW9uX3BvaW50cycpOworCisJJG5vZGVfcHJpbWFyeS0+c2FmZV9wc3Fs
KCdwb3N0Z3JlcycsIHEoQ1JFQVRFIEVYVEVOU0lPTiBpbmplY3Rpb25fcG9pbnRzKSk7CisKKwkj
IEZyZWV6ZSBhIGJhY2tlbmQgcmlnaHQgYWZ0ZXIgaXQgZHJvcHMgYW4gZXBoZW1lcmFsIHNsb3Qs
IGkuZS4gb25jZSB0aGUKKwkjIHNsb3QncyBhcnJheSBlbnRyeSBoYXMgYmVlbiBmcmVlZCBhbmQg
aXMgYXZhaWxhYmxlIGZvciByZXVzZS4KKwkkbm9kZV9wcmltYXJ5LT5zYWZlX3BzcWwoJ3Bvc3Rn
cmVzJywKKwkJcXtTRUxFQ1QgaW5qZWN0aW9uX3BvaW50c19hdHRhY2goJ2VwaGVtZXJhbC1zbG90
LXJlbGVhc2UtYWZ0ZXItZHJvcCcsICd3YWl0Jyl9CisJKTsKKworCSMgQ3JlYXRlIGEgbG9naWNh
bCBzbG90IHdpdGggYSBub24tZXhpc3RlbnQgb3V0cHV0IHBsdWdpbi4gIFRoZSBzbG90IGlzCisJ
IyBjcmVhdGVkIGFzIFJTX0VQSEVNRVJBTDsgdGhlIGJvZ3VzIHBsdWdpbiBtYWtlcyBjcmVhdGlv
biBFUlJPUiBvdXQsIGFuZAorCSMgdGhlIGVycm9yIHBhdGggY2FsbHMgUmVwbGljYXRpb25TbG90
UmVsZWFzZSgpLCB3aGljaCBkcm9wcyB0aGUgZXBoZW1lcmFsCisJIyBzbG90IGFuZCB0aGVuIGJs
b2NrcyBvbiB0aGUgaW5qZWN0aW9uIHBvaW50LiAgb25fZXJyb3Jfc3RvcCA9PiAwIGtlZXBzIHRo
ZQorCSMgc2Vzc2lvbiBhbGl2ZSBwYXN0IHRoZSBFUlJPUiBzbyBpdCBjYW4gc3RpbGwgcmVwb3J0
ICdkb25lX3JlbGVhc2UnLgorCW15ICRkcm9wcGVyID0KKwkgICRub2RlX3ByaW1hcnktPmJhY2tn
cm91bmRfcHNxbCgncG9zdGdyZXMnLCBvbl9lcnJvcl9zdG9wID0+IDApOworCSRkcm9wcGVyLT5x
dWVyeV91bnRpbCgKKwkJcXIvc3RhcnRfZHJvcC8sIHEoCitcZWNobyBzdGFydF9kcm9wCitTRUxF
Q1QgcGdfY3JlYXRlX2xvZ2ljYWxfcmVwbGljYXRpb25fc2xvdCgndGVzdF9zbG90X2Ryb3BwZWQn
LCAnbm9fc3VjaF9wbHVnaW4nLCBmYWxzZSk7CitcZWNobyBkb25lX3JlbGVhc2UKKykpOworCisJ
IyBXYWl0IHVudGlsIHRoZSBiYWNrZW5kIGlzIHBhcmtlZCBvbiB0aGUgaW5qZWN0aW9uIHBvaW50
LCB3aXRoIHRoZSBhcnJheQorCSMgZW50cnkgb2YgJ3Rlc3Rfc2xvdF9kcm9wcGVkJyBmcmVlZCBh
bmQgdXAgZm9yIGdyYWJzLgorCSRub2RlX3ByaW1hcnktPndhaXRfZm9yX2V2ZW50KCdjbGllbnQg
YmFja2VuZCcsCisJCSdlcGhlbWVyYWwtc2xvdC1yZWxlYXNlLWFmdGVyLWRyb3AnKTsKKworCSMg
QSBzZWNvbmQgYmFja2VuZCBjcmVhdGVzIGEgbmV3IHBlcnNpc3RlbnQgc2xvdCwgd2hpY2ggcmV1
c2VzIHRoZSBqdXN0CisJIyBmcmVlZCBhcnJheSBlbnRyeSAtLSB0aGUgdmVyeSBlbnRyeSB0aGUg
ZnJvemVuIGJhY2tlbmQgc3RpbGwgcG9pbnRzIGF0LgorCSRub2RlX3ByaW1hcnktPnNhZmVfcHNx
bCgncG9zdGdyZXMnLAorCQlxe1NFTEVDVCBwZ19jcmVhdGVfcGh5c2ljYWxfcmVwbGljYXRpb25f
c2xvdCgndGVzdF9zbG90X2NyZWF0ZWQnLCB0cnVlLCBmYWxzZSl9CisJKTsKKworCW15ICRiZWZv
cmUgPSAkbm9kZV9wcmltYXJ5LT5zYWZlX3BzcWwoJ3Bvc3RncmVzJywKKwkJcXtTRUxFQ1QgaW5h
Y3RpdmVfc2luY2UgRlJPTSBwZ19yZXBsaWNhdGlvbl9zbG90cyBXSEVSRSBzbG90X25hbWUgPSAn
dGVzdF9zbG90X2NyZWF0ZWQnfQorCSk7CisKKwkjIExldCB0aGUgZnJvemVuIGJhY2tlbmQgZmlu
aXNoIHJlbGVhc2luZy4gIFdpdGggdGhlIGJ1ZyBpdCBub3cgc2NyaWJibGVzIG9uCisJIyB0aGUg
cmV1c2VkIGVudHJ5OyB3aXRoIHRoZSBmaXggaXQgbGVhdmVzIGl0IHVudG91Y2hlZC4KKwkkbm9k
ZV9wcmltYXJ5LT5zYWZlX3BzcWwoJ3Bvc3RncmVzJywKKwkJcXtTRUxFQ1QgaW5qZWN0aW9uX3Bv
aW50c193YWtldXAoJ2VwaGVtZXJhbC1zbG90LXJlbGVhc2UtYWZ0ZXItZHJvcCcpfSk7CisJJGRy
b3BwZXItPnF1ZXJ5X3VudGlsKHFyL2RvbmVfcmVsZWFzZS8sICcnKTsKKworCW15ICRhZnRlciA9
ICRub2RlX3ByaW1hcnktPnNhZmVfcHNxbCgncG9zdGdyZXMnLAorCQlxe1NFTEVDVCBpbmFjdGl2
ZV9zaW5jZSBGUk9NIHBnX3JlcGxpY2F0aW9uX3Nsb3RzIFdIRVJFIHNsb3RfbmFtZSA9ICd0ZXN0
X3Nsb3RfY3JlYXRlZCd9CisJKTsKKworCWlzKCRhZnRlciwgJGJlZm9yZSwKKwkJJ3JlbGVhc2lu
ZyBhbiBlcGhlbWVyYWwgc2xvdCBtdXN0IG5vdCBtb2RpZnkgYSBzbG90IHRoYXQgcmV1c2VkIGl0
cyBlbnRyeScKKwkpOworCisJbXkgJHNsb3QgPSAkbm9kZV9wcmltYXJ5LT5zYWZlX3BzcWwoJ3Bv
c3RncmVzJywKKwkJcXtTRUxFQ1Qgc2xvdF9uYW1lLCBzbG90X3R5cGUgRlJPTSBwZ19yZXBsaWNh
dGlvbl9zbG90cyBXSEVSRSBzbG90X25hbWUgPSAndGVzdF9zbG90X2NyZWF0ZWQnfQorCSk7CisJ
aXMoJHNsb3QsICJ0ZXN0X3Nsb3RfY3JlYXRlZHxwaHlzaWNhbCIsICdyZXVzZWQgc2xvdCBpcyBp
bnRhY3QnKTsKKworCSRkcm9wcGVyLT5xdWl0OworCSRub2RlX3ByaW1hcnktPnNhZmVfcHNxbCgn
cG9zdGdyZXMnLAorCQlxe1NFTEVDVCBpbmplY3Rpb25fcG9pbnRzX2RldGFjaCgnZXBoZW1lcmFs
LXNsb3QtcmVsZWFzZS1hZnRlci1kcm9wJyl9KTsKK30KKwogIyBkb25lIHdpdGggdGhlIG5vZGUK
ICRub2RlX3ByaW1hcnktPnN0b3A7CiAK
--0000000000008797e70652f78ebb--