Re: Fix uninitialized xl_running_xacts padding
Alexander Kuzmenkov <akuzmenkov@tigerdata.com>
From: Alexander Kuzmenkov <akuzmenkov@tigerdata.com>
To: Andres Freund <andres@anarazel.de>,
Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>
Cc: 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-03-10T21:51:50Z
Lists: pgsql-hackers
On 16/02/2026 21:10, Andres Freund wrote: > I don't think it makes a whole lot of sense to tackle this specifically for > xl_running_xacts. 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. That's not random, that's server memory, right? Probably not another Heartbleed, but I'd rather initialize a few locals than find out. Happy to see this being worked on, these uninitialized WAL records are a major obstacle to enabling MemorySanitizer. I ran into this again today and this is how I found this thread. Unfortunately the MemorySanitizer can't even use the same suppressions as Valgrind, because the suppression architecture is different (can only remove the checks from a given function, not all stack traces that have this function like Valgrind does). Best regards Alexander Kuzmenkov TigerData
Commits
-
Add test for single-page VACUUM of hash index on INSERT
- 1f7947a48d0c 19 (unreleased) landed