Feedback-ID: i0fe9450f:Fastmail
Date: Mon, 16 Feb 2026 10:10:58 +0900
From: Michael Paquier <michael@paquier.xyz>
To: Thomas Munro <thomas.munro@gmail.com>
Cc: Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>,
	PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Fix uninitialized xl_running_xacts padding
Message-ID: <aZJuoggMUaXjwoDO@paquier.xyz>
References: <CAO6_Xqoxp7C+y0L==xZXH5V=9PjpBx4T9vJYs87EbxFp_9nwOA@mail.gmail.com>
 <CA+hUKG++LE6P6g4n+-QPHBwAnvcVRyG1tUnzscUriWAFHc6s6Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="pKZFJIeNbrwo32HL"
Content-Disposition: inline
In-Reply-To: <CA+hUKG++LE6P6g4n+-QPHBwAnvcVRyG1tUnzscUriWAFHc6s6Q@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/aZJuoggMUaXjwoDO%40paquier.xyz>
Precedence: bulk


--pKZFJIeNbrwo32HL
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

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

--pKZFJIeNbrwo32HL
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmmSbqIACgkQnvQgOdby
QH2dVxAAqPvOWkRnhIxsvigvPsfKsEPM/zV2co+vomAouIiohWkLWxiGMbO3OQ3A
FPT5WLctORDGicB0bB/g+TOzpx8U7r4/snrxZTXweRsRAepjwQsaVu4ohzQwuqOu
z1cY/jYc+LNb2XIwSY9kOTN0HKj+n8Sq7uaEb6qVlbg/P9vvlca9zKmhZrnSsQR+
gvaONnAMbMzk+8fuj8+S1gHeSJRS8ZXmvYE0eOHRXmhWY9nxWi1EvlOq/2yGZo/e
6zciFY5/6uj3N+mBV07h05W5UXOCE7uFlSzKew9lTbl83h/VmmNKb4a1PA6X8JsH
75yeCeF8kvTD5uG561SS4dQAa/5rs8Ea9Nb0hzjLLzfX1XPoaW3WVjWlmj7gHJx5
VO/IHYT5PbU7GiTfJvvafqQUlzM/N01tDnL4SqHdb5N8QGrSxqWHYS40d54/kW6+
6A/cy7McpcIzmgF+uLaYlg1t+xXOwtgpAPd+8So5AY3GZdZ9tAwzkug2JKHnWkMo
j/vJb2hQd0E7MOYGZQrrvWlMPJjLuY0EjR6cvjCKsD2/5EagYVdPPdMf8JKSdZ8f
u1UPQZkJTSmTYNMR+kEB3nnGMoSpAxmF85kroaq4psfIXkEwtpnLuUydu/n3Dqw9
AbvqQWSMcwVbgd2NSFwK6P2hPIDR+D0+TgtctRDBDpsgukFrxzU=
=Zlsm
-----END PGP SIGNATURE-----

--pKZFJIeNbrwo32HL--