MIME-Version: 1.0
References: <CAO6_Xqoxp7C+y0L==xZXH5V=9PjpBx4T9vJYs87EbxFp_9nwOA@mail.gmail.com>
 <CA+hUKG++LE6P6g4n+-QPHBwAnvcVRyG1tUnzscUriWAFHc6s6Q@mail.gmail.com>
 <aZJuoggMUaXjwoDO@paquier.xyz> <aZLHYtCsEldmm8Eu@ip-10-97-1-34.eu-west-3.compute.internal>
In-Reply-To: <aZLHYtCsEldmm8Eu@ip-10-97-1-34.eu-west-3.compute.internal>
From: Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>
Date: Mon, 16 Feb 2026 12:02:33 +0100
Message-ID: <CAO6_XqpGYneOe357s4QhOTYpU6UEgk3JJrBiyeuk-9n=f7p=Vw@mail.gmail.com>
Subject: Re: Fix uninitialized xl_running_xacts padding
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, Thomas Munro <thomas.munro@gmail.com>, 
	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/CAO6_XqpGYneOe357s4QhOTYpU6UEgk3JJrBiyeuk-9n%3Df7p%3DVw%40mail.gmail.com>
Precedence: bulk

On Fri, Feb 13, 2026 at 11:08=E2=80=AFAM Bertrand Drouvot
<bertranddrouvot.pg@gmail.com> wrote:
> It's not as important as when a struct which is used as an hash key has p=
adding
> bytes uninitialized (and byte comparisons are done on the key) but I'm al=
so
> +1 to make it "cleaner".

Yeah, there's no direct issue of having those uninitialized. The only
impact I can think of is reducing compression efficiency of the WAL
due to the random padding bytes.

On Mon, Feb 16, 2026 at 8:29=E2=80=AFAM Bertrand Drouvot
<bertranddrouvot.pg@gmail.com> wrote:
> > 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.
>
> That's also what I recall, and what we followed in [1].

I think that depends on the C standard used. With C99, there's no rule
for the padding bytes initialization.
With C11, in 6.7.9 Initialization of the standard: "the remainder of
the aggregate shall be initialized implicitly the same as objects that
have static storage duration", and with static storage will "every
member is initialized (recursively) according to these rules, and any
padding is initialized to zero bits".

So if I read this correctly, '{0}' will set padding bytes to 0 when
using C11. But given Postgres is using C99, that's not something we
can rely on?

> > 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.
>
> But in the case of this thread it's in the middle of the struct, so I'm n=
ot
> sure the "wasted" bytes would be elminated, would it?

Moving subxid_overflow before xids, wouldn't you have 3 bytes of
padding at the end of the struct for the whole struct alignment?