public inbox for [email protected]
help / color / mirror / Atom feedFrom: Zsolt Parragi <[email protected]>
To: Michael Paquier <[email protected]>
Cc: Bertrand Drouvot <[email protected]>
Cc: Alexander Kuzmenkov <[email protected]>
Cc: Heikki Linnakangas <[email protected]>
Cc: Andres Freund <[email protected]>
Cc: Anthonin Bonnefoy <[email protected]>
Cc: Thomas Munro <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: Fix uninitialized xl_running_xacts padding
Date: Wed, 18 Mar 2026 06:33:21 +0000
Message-ID: <CAN4CZFPWL_9-ZRO4PKaAWmoUxBnbOSdmxXX_zhairaG0eY4p_w@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<CALzhyqzKTRVsQGj+qDDRVs3Oo0EvffuQvVO0v4rbpWU=SoXKug@mail.gmail.com>
<CALzhyqzLh9iciLMvT9T-Z+o1ekOPpeP2p2r7tYXNZ8JMSea3Zg@mail.gmail.com>
<[email protected]>
<CALzhyqy27==NkjnXYysF1zJj_K2rX5kncJZ9fEdTRVszTjJisg@mail.gmail.com>
<[email protected]>
<CALzhyqxrc1ZHYmf5V8NE+yMboqVg7xZrQM7K2c7VS0p1v8z42w@mail.gmail.com>
<[email protected]>
<CAN4CZFN-Ab6J-zLRLiMvrj+ysYPJohwkiGALpcw4CWM_uHVU9g@mail.gmail.com>
<[email protected]>
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)
view thread (16+ messages) latest in thread
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], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Fix uninitialized xl_running_xacts padding
In-Reply-To: <CAN4CZFPWL_9-ZRO4PKaAWmoUxBnbOSdmxXX_zhairaG0eY4p_w@mail.gmail.com>
* 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