Re: Fix uninitialized xl_running_xacts padding - Mailing list pgsql-hackers

From Bertrand Drouvot
Subject Re: Fix uninitialized xl_running_xacts padding
Date
Msg-id aZLHYtCsEldmm8Eu@ip-10-97-1-34.eu-west-3.compute.internal
Whole thread Raw
In response to Re: Fix uninitialized xl_running_xacts padding  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Fix uninitialized xl_running_xacts padding
List pgsql-hackers
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=kkS6v0rSnQ0vWxhVncqVNYoOTsv6gOmcw@mail.gmail.com

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



pgsql-hackers by date:

Previous
From: shveta malik
Date:
Subject: Re: Skipping schema changes in publication
Next
From: Michael Paquier
Date:
Subject: Re: recovery.signal not cleaned up when both signal files are present