MIME-Version: 1.0
References: <CAO6_Xqoxp7C+y0L==xZXH5V=9PjpBx4T9vJYs87EbxFp_9nwOA@mail.gmail.com>
In-Reply-To: <CAO6_Xqoxp7C+y0L==xZXH5V=9PjpBx4T9vJYs87EbxFp_9nwOA@mail.gmail.com>
From: Thomas Munro <thomas.munro@gmail.com>
Date: Mon, 16 Feb 2026 13:17:56 +1300
Message-ID: <CA+hUKG++LE6P6g4n+-QPHBwAnvcVRyG1tUnzscUriWAFHc6s6Q@mail.gmail.com>
Subject: Re: Fix uninitialized xl_running_xacts padding
To: Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CA%2BhUKG%2B%2BLE6P6g4n%2B-QPHBwAnvcVRyG1tUnzscUriWAFHc6s6Q%40mail.gmail.com>
Precedence: bulk

On Fri, Feb 13, 2026 at 10:39=E2=80=AFPM Anthonin Bonnefoy
<anthonin.bonnefoy@datadoghq.com> 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 =3D {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?