public inbox for [email protected]  

help / color / mirror / Atom feed

From: Thomas Munro <[email protected]>
To: Anthonin Bonnefoy <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: Fix uninitialized xl_running_xacts padding
Date: Mon, 16 Feb 2026 13:17:56 +1300
Message-ID: <CA+hUKG++LE6P6g4n+-QPHBwAnvcVRyG1tUnzscUriWAFHc6s6Q@mail.gmail.com> (raw)
In-Reply-To: <CAO6_Xqoxp7C+y0L==xZXH5V=9PjpBx4T9vJYs87EbxFp_9nwOA@mail.gmail.com>
References: <CAO6_Xqoxp7C+y0L==xZXH5V=9PjpBx4T9vJYs87EbxFp_9nwOA@mail.gmail.com>

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?

view thread (2+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected]
  Subject: Re: Fix uninitialized xl_running_xacts padding
  In-Reply-To: <CA+hUKG++LE6P6g4n+-QPHBwAnvcVRyG1tUnzscUriWAFHc6s6Q@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox