Subject: Re: Fix uninitialized xl_running_xacts padding

From: Bertrand Drouvot <[email-masked]>
Date: Mon, 16 Feb 2026 07:29:38 +0000

Hi,

On Mon, Feb 16, 2026 at 10:10:58AM +0900, Michael Paquier wrote:
> On Mon, Feb 16, 2026 at 01:17:56PM +1300, Thomas Munro wrote:
> > Nitpick: the so-called universal zero initialiser syntax (var = {0})
> > 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.

That's also what I recall, and what we followed in [1].

> > 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?
> 
> 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 not
sure the "wasted" bytes would be elminated, would it?

Regards,

[1]: https://postgr.es/m/CAGECzQS37h0twutb=[email-masked]

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com

---

From: Anthonin Bonnefoy <[email-masked]>
Date: Mon, 16 Feb 2026 12:02:33 +0100

On Fri, Feb 13, 2026 at 11:08 AM Bertrand Drouvot
<[email-masked]> wrote:
> It's not as important as when a struct which is used as an hash key has padding
> bytes uninitialized (and byte comparisons are done on the key) but I'm also
> +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.

> 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?

> 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?