Re: Fix uninitialized xl_running_xacts padding

On 12/03/2026 20:23, Alexander Kuzmenkov wrote:
> The functions in the "0003" patch haven't surfaced in my "make 
> installcheck-parallel" runs with Valgrind, or the "make check" with 
> MemorySanitizer. However, I could hit most of them with some fuzzing. 
> The only exception was `xl_hash_vacuum_one_page` but that's probably 
> also triggerable.

Cool. It would be nice to have test coverage for every WAL record type. 
Could you add tests to the test suite to hit those cases?

> I noticed that we also use `sizeof` in some WAL functions, so probably 
> the tail padding can also be written to WAL? For example, consider this:
> (gdb) ptype/o gistxlogPageSplit
> type = struct gistxlogPageSplit {
> /*      0      |       4 */    BlockNumber origrlink;
> /* XXX  4-byte hole      */
> /*      8      |       8 */    GistNSN orignsn;
> /*     16      |       1 */    _Bool origleaf;
> /* XXX  1-byte hole      */
> /*     18      |       2 */    uint16 npage;
> /*     20      |       1 */    _Bool markfollowright;
> /* XXX  3-byte padding   */
> 
>                                 /* total size (bytes):   24 */
>                               }
> 
> And then we do  XLogRegisterData((char *) &xlrec, 
> sizeof(gistxlogPageSplit));

Yep.

> In general, I'm wondering what our approach to this should be. Several 
> potential improvements were mentioned, but I think for now we could 
> focus on removing the Valgrind suppression. This is a meaningful 
> improvement that uses the existing test tools.

+1. I think it's a good goal that no uninitialized bytes reach the WAL. 
It's not a security issue or anything, but just seems like good hygiene.

> Do we want to defensively zero-initialize every case that seems to
> be potentially affected, i.e. written to WAL and has holes/tail
> padding? That sounds cheap and simple and probably even
> backportable. In the "0001" patch, there are several cases where no
> padding goes into WAL, I can remove these. For example, the use of
> xl_brin_createidx in brinbuild() does not have this problem.
Sounds good to me.

- Heikki