> 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/
