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