public inbox for [email protected]
help / color / mirror / Atom feedFrom: Michael Paquier <[email protected]>
To: Thomas Munro <[email protected]>
Cc: Anthonin Bonnefoy <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: Fix uninitialized xl_running_xacts padding
Date: Mon, 16 Feb 2026 10:10:58 +0900
Message-ID: <[email protected]> (raw)
In-Reply-To: <CA+hUKG++LE6P6g4n+-QPHBwAnvcVRyG1tUnzscUriWAFHc6s6Q@mail.gmail.com>
References: <CAO6_Xqoxp7C+y0L==xZXH5V=9PjpBx4T9vJYs87EbxFp_9nwOA@mail.gmail.com>
<CA+hUKG++LE6P6g4n+-QPHBwAnvcVRyG1tUnzscUriWAFHc6s6Q@mail.gmail.com>
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. We could couple a {0} with some dummy fields in
xl_running_xacts, of course. But actually, there may be an even
smarter move in this case: LogCurrentRunningXacts() uses
MinSizeOfXactRunningXacts to store the data of a xl_running_xacts,
based on an offset of xl_running_xacts.xids. So we could move
subxid_overflow at the end of xl_running_xacts before xids, shaving
these padding bytes away while inserting the record's data.
> 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.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, 2-signature.asc)
download
view thread (2+ messages)
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: Fix uninitialized xl_running_xacts padding
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox