Re: Fix uninitialized xl_running_xacts padding
| От | Chao Li |
|---|---|
| Тема | Re: Fix uninitialized xl_running_xacts padding |
| Дата | |
| Msg-id | 4AECB8A0-A04A-4CE5-9161-B8C28799D4CB@gmail.com обсуждение |
| Ответ на | Re: Fix uninitialized xl_running_xacts padding (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>) |
| Список | 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/
В списке pgsql-hackers по дате отправления: