Subject: Fix uninitialized xl_running_xacts padding

From: Anthonin Bonnefoy <[email-masked]>
Date: Fri, 13 Feb 2026 10:39:14 +0100

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

---

From: Michael Paquier <[email-masked]>
Date: Fri, 13 Feb 2026 18:50:08 +0900

> structure in LogCurrentRunningXacts using MemSet.

This uninitialized padding exists for as long as this code exists,
down to efc16ea52067.  No objection here to clean up that on HEAD.
--
Michael