Subject: Re: Fix uninitialized xl_running_xacts padding

From: Thomas Munro <[email-masked]>
Date: Mon, 16 Feb 2026 13:17:56 +1300

On Fri, Feb 13, 2026 at 10:39 PM Anthonin Bonnefoy
<[email-masked]> wrote:
> 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.

Nitpick: the so-called universal zero initialiser syntax (var = {0})
is a nicer way to do this and generally preferred in new code AFAIK.

But in this case, it seems we don't actually worry about initialising
WAL padding bytes in general.  valgrind.supp has an entry to prevent
warnings about it.  Should we?

---

From: Michael Paquier <[email-masked]>
Date: Mon, 16 Feb 2026 10:10:58 +0900

> is a nicer way to do this and generally preferred in new code AFAIK.

My memory on the matter may be fuzzy, of course, but the initializer
does not guarantee that the padding bytes are initialized to zero
because the padding bytes are not associated to a member in the
structure.  A memset(0), however, makes sure that the padding bytes
are full of zeros by taking into account the full size of the
structure.  We could couple a {0} with some dummy fields in
xl_running_xacts, of course.  But actually, there may be an even
smarter move in this case: LogCurrentRunningXacts() uses
MinSizeOfXactRunningXacts to store the data of a xl_running_xacts,
based on an offset of xl_running_xacts.xids.  So we could move
subxid_overflow at the end of xl_running_xacts before xids, shaving
these padding bytes away while inserting the record's data.

> warnings about it.  Should we?

True about the initialization part, mostly I guess, still we tend to
worry about eliminating padding because these are wasted bytes in the
WAL records.  For example, xlhp_freeze_plans has two bytes of padding,
that we eliminate while inserting its record by splitting the
FLEXIBLE_ARRAY_MEMBER part.
--
Michael