MIME-Version: 1.0
References: <b607e42e-34ff-414a-b727-dd5ec70babe3@timescale.com>
 <ed73b90b-e153-41ba-a626-2e13da42d6c8@iki.fi>
 <CALzhyqzKTRVsQGj+qDDRVs3Oo0EvffuQvVO0v4rbpWU=SoXKug@mail.gmail.com>
 <CALzhyqzLh9iciLMvT9T-Z+o1ekOPpeP2p2r7tYXNZ8JMSea3Zg@mail.gmail.com>
 <f2875d6b-5ff6-4744-b151-f5ab54cbd2c5@iki.fi>
 <CALzhyqy27==NkjnXYysF1zJj_K2rX5kncJZ9fEdTRVszTjJisg@mail.gmail.com>
 <70674869-2829-4b06-ab93-2f82ea51578c@iki.fi>
 <CALzhyqxrc1ZHYmf5V8NE+yMboqVg7xZrQM7K2c7VS0p1v8z42w@mail.gmail.com>
 <ablMZvnGhX8h5GgK@ip-10-97-1-34.eu-west-3.compute.internal>
 <CAN4CZFN-Ab6J-zLRLiMvrj+ysYPJohwkiGALpcw4CWM_uHVU9g@mail.gmail.com>
 <aboL57TwiaOBTyXJ@paquier.xyz>
In-Reply-To: <aboL57TwiaOBTyXJ@paquier.xyz>
From: Zsolt Parragi <zsolt.parragi@percona.com>
Date: Wed, 18 Mar 2026 06:33:21 +0000
Message-ID: 
 <CAN4CZFPWL_9-ZRO4PKaAWmoUxBnbOSdmxXX_zhairaG0eY4p_w@mail.gmail.com>
Subject: Re: Fix uninitialized xl_running_xacts padding
To: Michael Paquier <michael@paquier.xyz>
Cc: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>,
	Alexander Kuzmenkov <akuzmenkov@tigerdata.com>,
 Heikki Linnakangas <hlinnaka@iki.fi>,
	Andres Freund <andres@anarazel.de>,
 Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>,
	Thomas Munro <thomas.munro@gmail.com>,
 PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: 
 <https://www.postgresql.org/message-id/CAN4CZFPWL_9-ZRO4PKaAWmoUxBnbOSdmxXX_zhairaG0eY4p_w%40mail.gmail.com>
Precedence: bulk

Thank you for the feedback!

>  but the invasiveness and the footprint this involves in
> the WAL insertion code paths makes it a no-go for me.

Invasiveness is an option I choose, not a requirement.

In an alternative version, this could work in a "less strict" mode, on
top of Alexander's memset patch, verifying that: if we see a function
that uses XLogRegisterData, and the variable passed to it is defined
in the same function/translation unit (which is most of the case), we
require that variable to be well initialized - either all fields have
to be specified by hand, or it needs an initializer block/memset at
the beginning -- or if it has compiler generated padding inside, it
requires memset, as that's the only thing guaranteed to initialize it.
Similarly instead of requiring explicit padding added to the end of
the struct, it could instead verify that 1. the SizeOf macros are
correctly defined, refer to the proper size 2. if a SizeOf macro is
defined, the struct is properly memset at every location where it it
used

In that version, there would be little or no change over Alexander's
previous patch, other than adding pg-tidy itself to the build. I can
also create a version with that approach, it should be relatively
simply as I won't have to modify the WAL structs/calls like in this
version.

> Valgrind has proved to be quite useful over the years. Sure, it takes
> more time to run it, but for this specific issue I don't see why we
> should not continue relying on it

I'm not saying that we should rely on valgrind, it is a good tool and
it possibly catches things this wouldn't. This would be an additional
tool, offering the advantage of being quick and integrated into the
build. (Valgrind is also integrated, but it is also slow, I don't
think everyone runs it regularly as part of normal development)