Re: Fix uninitialized xl_running_xacts padding
| От | Heikki Linnakangas |
|---|---|
| Тема | Re: Fix uninitialized xl_running_xacts padding |
| Дата | |
| Msg-id | ed73b90b-e153-41ba-a626-2e13da42d6c8@iki.fi обсуждение исходный текст |
| Ответ на | Re: Fix uninitialized xl_running_xacts padding (Alexander Kuzmenkov <akuzmenkov@tigerdata.com>) |
| Ответы |
Re: Fix uninitialized xl_running_xacts padding
|
| Список | pgsql-hackers |
On 10/03/2026 23:51, Alexander Kuzmenkov wrote: > 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). +1 for initializing all padding in WAL records. In fact I thought that we already did that. (Except in this case, apparently) - Heikki
В списке pgsql-hackers по дате отправления: