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  (Thomas Munro <thomas.munro@gmail.com>)
Re: BUG #17619: AllocSizeIsValid violation in parallel hash join  (Peter Geoghegan <pg@bowt.ie>)
Список 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 по дате отправления:

Предыдущее
От: Thomas Munro
Дата:
Сообщение: Re: BUG #17619: AllocSizeIsValid violation in parallel hash join
Следующее
От: Richard Guo
Дата:
Сообщение: Re: BUG #17618: unnecessary filter column <> text even after adding index