Re: Fix uninitialized xl_running_xacts padding
Zsolt Parragi <zsolt.parragi@percona.com>
From: Zsolt Parragi <zsolt.parragi@percona.com>
To: Andres Freund <andres@anarazel.de>
Cc: Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>, Bertrand Drouvot <bertranddrouvot.pg@gmail.com>,
Michael Paquier <michael@paquier.xyz>, Thomas Munro <thomas.munro@gmail.com>,
PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2026-02-17T08:00:32Z
Lists: pgsql-hackers
Attachments
- current_errors.txt (text/plain)
- walstructcheck (application/octet-stream)
> Until now we just accepted that WAL insertions can contain > random padding. If we don't want that, we should go around and make sure that > there is no padding (or padding is initialized) for *all* WAL records, > document that as the rule, and remove the relevant valgrind suppressions. While this would be a nice requirement, I don't think we can enforce it for extensions, only for the core, as C has no capabilities to add a rule for this. But we could enforce it for the core code, what do you think about a script that similarly to headercheck detects WAL record issues automatically? That's also good for detecting the current issues, see attached script and the results I get when executing it on the current master branch. Notes: * It tries to find the related SizeOf macros, and if that exists, accepts trailing padding if it's correctly calculated. But it currently doesn't verify that the SizeOf macro is currently used everywhere (that also seems doable with some greps) * It also has a whitelist for non wal structs in these headers and 2 cases where we explicitly document that padding is ok (not sure if this latter should be really in the whitelist or not)
Commits
-
Add test for single-page VACUUM of hash index on INSERT
- 1f7947a48d0c 19 (unreleased) landed