Re: Fix uninitialized xl_running_xacts padding
| От | Alexander Kuzmenkov |
|---|---|
| Тема | Re: Fix uninitialized xl_running_xacts padding |
| Дата | |
| Msg-id | b607e42e-34ff-414a-b727-dd5ec70babe3@timescale.com обсуждение исходный текст |
| Ответ на | Re: Fix uninitialized xl_running_xacts padding (Andres Freund <andres@anarazel.de>) |
| Ответы |
Re: Fix uninitialized xl_running_xacts padding
|
| Список | pgsql-hackers |
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). Best regards Alexander Kuzmenkov TigerData
В списке pgsql-hackers по дате отправления: