Re: BUG #17619: AllocSizeIsValid violation in parallel hash join
От | Tom Lane |
---|---|
Тема | Re: BUG #17619: AllocSizeIsValid violation in parallel hash join |
Дата | |
Msg-id | 2169849.1663975173@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #17619: AllocSizeIsValid violation in parallel hash join (Thomas Munro <thomas.munro@gmail.com>) |
Ответы |
Re: BUG #17619: AllocSizeIsValid violation in parallel hash join
Re: BUG #17619: AllocSizeIsValid violation in parallel hash join |
Список | pgsql-bugs |
Thomas Munro <thomas.munro@gmail.com> writes: > While testing with that module I found another bug: the > per-participant npages counter was not explicitly initialised to zero > in sts_initialize(). That wasn't exactly a problem when the code was > written because new DSM memory is always zeroed and this always > happens in new DSM memory, but it shows up in this test module because > it uses palloc() memory instead. It *is* a problem since v14, if you > use min_dynamic_shared_memory for a pool of recyclable shared memory, > because then it is not zeroed. That's a fairly scary observation. What other places are silently expecting such memory to be zeroed? Do we need to fix things so that min_dynamic_shared_memory doesn't break this API? regards, tom lane
В списке pgsql-bugs по дате отправления: