MIME-Version: 1.0
From: Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>
Date: Fri, 13 Feb 2026 10:39:14 +0100
Message-ID: <CAO6_Xqoxp7C+y0L==xZXH5V=9PjpBx4T9vJYs87EbxFp_9nwOA@mail.gmail.com>
Subject: Fix uninitialized xl_running_xacts padding
To: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Content-Type: multipart/mixed; boundary="000000000000814053064ab161af"
Archived-At: <https://www.postgresql.org/message-id/CAO6_Xqoxp7C%2By0L%3D%3DxZXH5V%3D9PjpBx4T9vJYs87EbxFp_9nwOA%40mail.gmail.com>
Precedence: bulk

--000000000000814053064ab161af
Content-Type: text/plain; charset="UTF-8"

Hi,

While looking at the generated WAL, I've found out that RUNNING_XACTS
records contain data from uninitialized padding bytes. This can be
seen by generating a simple WAL with "SELECT pg_switch_wal();
CHECKPOINT;"

Finding the position of the running_xacts record with pg_waldump:
rmgr: Standby     len (rec/tot):     54/    54, tx:          0, lsn:
0/02D001D0, prev 0/02D00198, desc: RUNNING_XACTS nextXid 803
latestCompletedXid 801 oldestRunningXid 802; 1 xacts: 802

And getting the content of the running xacts record, skipping the 24
bytes of record header:
hexdump -C -s $((0x1d0 + 24)) -n 30 00000001000000000000002D

Which yields the following:
ff 1c 01 00 00 00 00 00  00 00 00 ca ce 9b 23 03
00 00 22 03 00 00 21 03  00 00 22 03 00 00

Looking at the xl_running_xacts, structure, we have the following:
id: ff
length: 1c
xcnt: 01 00 00 00
subxcnt: 00 00 00 00
subxid_overflow: 00
padding: ca ce 9b
nextXid: 00 00 22 03
...

The 3 bytes of padding after subxid_overflow were left uninitialized,
leading to the random 'ca ce 9b' data being written in the WAL. The
attached patch fixes the issue by zeroing the xl_running_xacts
structure in LogCurrentRunningXacts using MemSet.

Regards,
Anthonin Bonnefoy

--000000000000814053064ab161af
Content-Type: application/octet-stream; 
	name="v1-0001-Zero-pad-bytes-of-xl_running_xacts.patch"
Content-Disposition: attachment; 
	filename="v1-0001-Zero-pad-bytes-of-xl_running_xacts.patch"
Content-Transfer-Encoding: base64
Content-ID: <f_mlkonh3m0>
X-Attachment-Id: f_mlkonh3m0

RnJvbSA1NTViMWRkZjRkYWE5ODNhNTM5YTFlZjA0NjFiZmZlMTVmOGQ1NzExIE1vbiBTZXAgMTcg
MDA6MDA6MDAgMjAwMQpGcm9tOiBBbnRob25pbiBCb25uZWZveSA8YW50aG9uaW4uYm9ubmVmb3lA
ZGF0YWRvZ2hxLmNvbT4KRGF0ZTogRnJpLCAxMyBGZWIgMjAyNiAwOToyMjo0NSArMDEwMApTdWJq
ZWN0OiBaZXJvIHBhZCBieXRlcyBvZiB4bF9ydW5uaW5nX3hhY3RzCgp4bF9ydW5uaW5nX3hhY3Rz
IGhhcyAzIHBhZGRpbmcgYnl0ZXMgYWZ0ZXIgc3VieGlkX292ZXJmbG93IHdoaWNoIGFyZQpjdXJy
ZW50bHkgdW5pbml0aWFsaXplZC4gV2hlbiB0aGUgc3RydWN0IGlzIHdyaXR0ZW4sIHRob3NlIHVu
aW5pdGlhbGl6ZWQKYnl0ZXMgYXJlIGFsc28gd3JpdHRlbiBpbiB0aGUgV0FMLgoKVGhpcyBwYXRj
aCBlbnN1cmVzIHRob3NlIHBhZCBieXRlcyBhcmUgemVyb2VkLgotLS0KIHNyYy9iYWNrZW5kL3N0
b3JhZ2UvaXBjL3N0YW5kYnkuYyB8IDEgKwogMSBmaWxlIGNoYW5nZWQsIDEgaW5zZXJ0aW9uKCsp
CgpkaWZmIC0tZ2l0IGEvc3JjL2JhY2tlbmQvc3RvcmFnZS9pcGMvc3RhbmRieS5jIGIvc3JjL2Jh
Y2tlbmQvc3RvcmFnZS9pcGMvc3RhbmRieS5jCmluZGV4IDdmYThkOTI0N2UwLi40ZGI5NDRjM2Ex
NiAxMDA2NDQKLS0tIGEvc3JjL2JhY2tlbmQvc3RvcmFnZS9pcGMvc3RhbmRieS5jCisrKyBiL3Ny
Yy9iYWNrZW5kL3N0b3JhZ2UvaXBjL3N0YW5kYnkuYwpAQCAtMTM1NSw2ICsxMzU1LDcgQEAgTG9n
Q3VycmVudFJ1bm5pbmdYYWN0cyhSdW5uaW5nVHJhbnNhY3Rpb25zIEN1cnJSdW5uaW5nWGFjdHMp
CiAJeGxfcnVubmluZ194YWN0cyB4bHJlYzsKIAlYTG9nUmVjUHRyCXJlY3B0cjsKIAorCU1lbVNl
dCgmeGxyZWMsIDAsIHNpemVvZih4bF9ydW5uaW5nX3hhY3RzKSk7CiAJeGxyZWMueGNudCA9IEN1
cnJSdW5uaW5nWGFjdHMtPnhjbnQ7CiAJeGxyZWMuc3VieGNudCA9IEN1cnJSdW5uaW5nWGFjdHMt
PnN1YnhjbnQ7CiAJeGxyZWMuc3VieGlkX292ZXJmbG93ID0gKEN1cnJSdW5uaW5nWGFjdHMtPnN1
YnhpZF9zdGF0dXMgIT0gU1VCWElEU19JTl9BUlJBWSk7Ci0tIAoyLjUyLjAKCg==
--000000000000814053064ab161af--