public inbox for [email protected]
help / color / mirror / Atom feedRe: Fix uninitialized xl_running_xacts padding
2+ messages / 2 participants
[nested] [flat]
* Re: Fix uninitialized xl_running_xacts padding
@ 2026-02-16 07:29 Bertrand Drouvot <[email protected]>
0 siblings, 1 reply; 2+ messages in thread
From: Bertrand Drouvot @ 2026-02-16 07:29 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Thomas Munro <[email protected]>; Anthonin Bonnefoy <[email protected]>; 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
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: Fix uninitialized xl_running_xacts padding
@ 2026-02-16 11:02 Anthonin Bonnefoy <[email protected]>
parent: Bertrand Drouvot <[email protected]>
0 siblings, 0 replies; 2+ messages in thread
From: Anthonin Bonnefoy @ 2026-02-16 11:02 UTC (permalink / raw)
To: Bertrand Drouvot <[email protected]>; +Cc: Michael Paquier <[email protected]>; Thomas Munro <[email protected]>; pgsql-hackers
On Fri, Feb 13, 2026 at 11:08 AM Bertrand Drouvot
<[email protected]> 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.
On Mon, Feb 16, 2026 at 8:29 AM Bertrand Drouvot
<[email protected]> 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 not
> 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?
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2026-02-16 11:02 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2026-02-16 07:29 Re: Fix uninitialized xl_running_xacts padding Bertrand Drouvot <[email protected]>
2026-02-16 11:02 ` Anthonin Bonnefoy <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox