Re: Fix uninitialized xl_running_xacts padding

Chao Li <li.evan.chao@gmail.com>

From: Chao Li <li.evan.chao@gmail.com>
To: Bertrand Drouvot <bertranddrouvot.pg@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, Anthonin Bonnefoy <anthonin.bonnefoy@datadoghq.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2026-02-15T23:39:09Z
Lists: pgsql-hackers

> On Feb 13, 2026, at 18:08, Bertrand Drouvot <bertranddrouvot.pg@gmail.com> wrote:
> 
> Hi,
> 
> On Fri, Feb 13, 2026 at 06:50:08PM +0900, Michael Paquier wrote:
>> On Fri, Feb 13, 2026 at 10:39:14AM +0100, Anthonin Bonnefoy wrote:
>>> The 3 bytes of padding after subxid_overflow were left uninitialized,
>>> leading to the random 'ca ce 9b' data being written in the WAL. The
>>> attached patch fixes the issue by zeroing the xl_running_xacts
>>> structure in LogCurrentRunningXacts using MemSet.
>> 
>> This uninitialized padding exists for as long as this code exists,
>> down to efc16ea52067.  No objection here to clean up that on HEAD.
> 
> It's not as important as when a struct which is used as an hash key has padding
> bytes uninitialized (and byte comparisons are done on the key) but I'm also
> +1 to make it "cleaner".
> 
> Regards,
> 
> -- 
> Bertrand Drouvot
> PostgreSQL Contributors Team
> RDS Open Source Databases
> Amazon Web Services: https://aws.amazon.com
> 

I have no objection on cleanup the padding bytes. As the structure is small, maybe we can use {0} initializer:
```
xl_running_xacts xlrec = {0};
```
That will allow compilers to optimize the initialization. Anyway, that’s not a big deal, no strong opinion here.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/







Commits

  1. Add test for single-page VACUUM of hash index on INSERT