MIME-Version: 1.0
From: JoongHyuk Shin <sjh910805@gmail.com>
Date: Fri, 17 Apr 2026 15:50:01 +0900
Message-ID: 
 <CACSdjfMQYL3DV-3inrxdReqpFMOky4JxLbN0gTTY+qGJqrUJXw@mail.gmail.com>
Subject: [PATCH] Fix TOCTOU race in ReplicationSlotsComputeRequiredLSN()
To: pgsql-hackers@lists.postgresql.org
Content-Type: multipart/mixed; boundary="0000000000006c31a0064fa25cbc"
Archived-At: 
 <https://www.postgresql.org/message-id/CACSdjfMQYL3DV-3inrxdReqpFMOky4JxLbN0gTTY%2BqGJqrUJXw%40mail.gmail.com>
Precedence: bulk

--0000000000006c31a0064fa25cbc
Content-Type: multipart/alternative; boundary="0000000000006c319e064fa25cba"

--0000000000006c319e064fa25cba
Content-Type: text/plain; charset="UTF-8"

Hi,

Commit 2a5225b99d7 fixed a race in ReplicationSlotsComputeRequiredXmin()
where ReplicationSlotControlLock was released before the global xmin
update, allowing a concurrent backend to overwrite a correct value with
a stale one.

ReplicationSlotsComputeRequiredLSN() has the same problem, it releases the
lock before calling XLogSetReplicationSlotMinimumLSN(), so a stale minimum
LSN can overwrite a correct (lower) one, potentially leading to premature
WAL removal.

The attached patch moves LWLockRelease() to after the LSN update,
matching the xmin fix. Since 2a5225b99d7 was backpatched to all supported
versions, I believe this should be as well.

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

<div dir=3D"ltr"><div style=3D"color:rgb(59,59,59);font-family:Consolas,&qu=
ot;Courier New&quot;,monospace;font-size:14px;line-height:19px;white-space:=
pre"><div>Hi,</div><br><div>Commit 2a5225b99d7 fixed a race in ReplicationS=
lotsComputeRequiredXmin()</div><div>where ReplicationSlotControlLock was re=
leased before the global xmin</div><div>update, allowing a concurrent backe=
nd to overwrite a correct value with</div><div>a stale one.</div><br><div>R=
eplicationSlotsComputeRequiredLSN() has the same problem,=20
it releases the lock before calling XLogSetReplicationSlotMinimumLSN(),=20
so a stale minimum LSN can overwrite a correct (lower) one,=20
potentially leading to premature WAL removal.</div><br><div>The attached pa=
tch moves LWLockRelease() to after the LSN update,</div><div>matching the x=
min fix.
Since 2a5225b99d7 was backpatched to all supported versions,=20
I believe this should be as well.</div><div>
</div></div></div>

--0000000000006c319e064fa25cba--

--0000000000006c31a0064fa25cbc
Content-Type: application/octet-stream;
	name="0001-Fix-TOCTOU-race-in-ReplicationSlotsComputeRequiredLS.patch"
Content-Disposition: attachment;
	filename="0001-Fix-TOCTOU-race-in-ReplicationSlotsComputeRequiredLS.patch"
Content-Transfer-Encoding: base64
Content-ID: <f_mo2jsagr0>
X-Attachment-Id: f_mo2jsagr0

RnJvbSA2M2MzYjQ2OWQ4ZTNhZGRiZTA5Mjg2MWIwNmZiMjUxYWZhNGFjMzJhIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBKb29uZ0h5dWsgU2hpbiA8c2poOTEwODA1QGdtYWlsLmNvbT4K
RGF0ZTogRnJpLCAxNyBBcHIgMjAyNiAxNTowNzoxMSArMDkwMApTdWJqZWN0OiBbUEFUQ0hdIEZp
eCBUT0NUT1UgcmFjZSBpbiBSZXBsaWNhdGlvblNsb3RzQ29tcHV0ZVJlcXVpcmVkTFNOKCkKClJl
cGxpY2F0aW9uU2xvdHNDb21wdXRlUmVxdWlyZWRMU04oKSByZWxlYXNlZCBSZXBsaWNhdGlvblNs
b3RDb250cm9sTG9jawpiZWZvcmUgY2FsbGluZyBYTG9nU2V0UmVwbGljYXRpb25TbG90TWluaW11
bUxTTigpLCBjcmVhdGluZyBhIHdpbmRvdwp3aGVyZSBhIGNvbmN1cnJlbnQgYmFja2VuZCBjb3Vs
ZCBjb21wdXRlIGEgY29ycmVjdCAobG93ZXIpIG1pbmltdW0gTFNOLApvbmx5IGZvciB0aGUgZmly
c3QgYmFja2VuZCB0byBvdmVyd3JpdGUgaXQgd2l0aCBhIHN0YWxlIChoaWdoZXIpIHZhbHVlLgpU
aGlzIGNvdWxkIGxlYWQgdG8gcHJlbWF0dXJlIFdBTCByZW1vdmFsLgoKVGhlIGV4YWN0IHNhbWUg
cGF0dGVybiB3YXMgYWxyZWFkeSBmaXhlZCBmb3IgdGhlIHhtaW4gdmFyaWFudCBpbiBjb21taXQK
MmE1MjI1Yjk5ZDcsIHdoaWNoIG1vdmVkIHRoZSBsb2NrIHJlbGVhc2UgaW4KUmVwbGljYXRpb25T
bG90c0NvbXB1dGVSZXF1aXJlZFhtaW4oKSB0byBhZnRlciB0aGUgZ2xvYmFsIHhtaW4gdXBkYXRl
LgpUaGUgTFNOIGZ1bmN0aW9uIHdhcyBtaXNzZWQgaW4gdGhhdCBmaXguCgpNb3ZlIExXTG9ja1Jl
bGVhc2UoKSB0byBhZnRlciBYTG9nU2V0UmVwbGljYXRpb25TbG90TWluaW11bUxTTigpIHNvIHRo
ZQpsb2NrIGlzIGhlbGQgZm9yIHRoZSBlbnRpcmUgY29tcHV0ZS1hbmQtdXBkYXRlIHNlcXVlbmNl
LCBtYXRjaGluZyB0aGUKeG1pbiBmdW5jdGlvbidzIGJlaGF2aW9yLgoKQXV0aG9yOiBKb29uZ0h5
dWsgU2hpbiA8c2poOTEwODA1QGdtYWlsLmNvbT4KLS0tCiBzcmMvYmFja2VuZC9yZXBsaWNhdGlv
bi9zbG90LmMgfCA3ICsrKysrKy0KIDEgZmlsZSBjaGFuZ2VkLCA2IGluc2VydGlvbnMoKyksIDEg
ZGVsZXRpb24oLSkKCmRpZmYgLS1naXQgYS9zcmMvYmFja2VuZC9yZXBsaWNhdGlvbi9zbG90LmMg
Yi9zcmMvYmFja2VuZC9yZXBsaWNhdGlvbi9zbG90LmMKaW5kZXggODNmY2RlNzQ3MTguLjBkODdm
MGZkMzlkIDEwMDY0NAotLS0gYS9zcmMvYmFja2VuZC9yZXBsaWNhdGlvbi9zbG90LmMKKysrIGIv
c3JjL2JhY2tlbmQvcmVwbGljYXRpb24vc2xvdC5jCkBAIC0xMzEyLDYgKzEzMTIsMTEgQEAgUmVw
bGljYXRpb25TbG90c0NvbXB1dGVSZXF1aXJlZExTTih2b2lkKQogCiAJQXNzZXJ0KFJlcGxpY2F0
aW9uU2xvdEN0bCAhPSBOVUxMKTsKIAorCS8qCisJICogSG9sZCBSZXBsaWNhdGlvblNsb3RDb250
cm9sTG9jayB1bnRpbCBhZnRlciB1cGRhdGluZyB0aGUgbWluaW11bSBMU04uCisJICogV2l0aG91
dCB0aGlzLCBhIGNvbmN1cnJlbnQgYmFja2VuZCBjb3VsZCBjb21wdXRlIGEgY29ycmVjdCAobG93
ZXIpCisJICogbWluaW11bSBhbmQgdGhlbiBoYXZlIGl0IG92ZXJ3cml0dGVuIGJ5IG91ciBzdGFs
ZSAoaGlnaGVyKSB2YWx1ZS4KKwkgKi8KIAlMV0xvY2tBY3F1aXJlKFJlcGxpY2F0aW9uU2xvdENv
bnRyb2xMb2NrLCBMV19TSEFSRUQpOwogCWZvciAoaSA9IDA7IGkgPCBtYXhfcmVwbGljYXRpb25f
c2xvdHMgKyBtYXhfcmVwYWNrX3JlcGxpY2F0aW9uX3Nsb3RzOyBpKyspCiAJewpAQCAtMTM1Nyw5
ICsxMzYyLDkgQEAgUmVwbGljYXRpb25TbG90c0NvbXB1dGVSZXF1aXJlZExTTih2b2lkKQogCQkJ
IHJlc3RhcnRfbHNuIDwgbWluX3JlcXVpcmVkKSkKIAkJCW1pbl9yZXF1aXJlZCA9IHJlc3RhcnRf
bHNuOwogCX0KLQlMV0xvY2tSZWxlYXNlKFJlcGxpY2F0aW9uU2xvdENvbnRyb2xMb2NrKTsKIAog
CVhMb2dTZXRSZXBsaWNhdGlvblNsb3RNaW5pbXVtTFNOKG1pbl9yZXF1aXJlZCk7CisJTFdMb2Nr
UmVsZWFzZShSZXBsaWNhdGlvblNsb3RDb250cm9sTG9jayk7CiB9CiAKIC8qCi0tIAoyLjUyLjAK
Cg==
--0000000000006c31a0064fa25cbc--