Re: BUG #17619: AllocSizeIsValid violation in parallel hash join

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: BUG #17619: AllocSizeIsValid violation in parallel hash join
Дата
Msg-id CAH2-WzknY8v7CWP-qZB071_i-QP7MpTYFxAkrmR_r3LZRc9CLQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG #17619: AllocSizeIsValid violation in parallel hash join  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: BUG #17619: AllocSizeIsValid violation in parallel hash join  (Peter Geoghegan <pg@bowt.ie>)
Список pgsql-bugs
On Tue, Sep 27, 2022 at 9:24 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> That scares me too, but how come things aren't falling over
> routinely?  Can we even make a test case where it breaks?

I'm not completely sure, but I think that the explanation might just
be that the memory is likely to be "zero initialized" in practice.
Even when it isn't we're still only talking about instrumentation
counters that start out with garbage values -- so nothing truly
critical.

My main concern is the big picture, and not so much these specific
lapses. Less benign crash bugs like the one fixed by commit 662ba729
are much less likely with proper testing.

> I think I'd personally prefer to treat such memory more like we
> treat palloc'd memory, ie there's *not* a guarantee of zero
> initialization and indeed testing builds intentionally clobber it.

Isn't that already how it works? The problem is that it's not
particularly clear that that's how it works right now. And that the
dynamic shared memory stuff isn't tested via the same techniques that
we use for palloc.

We could more or less apply the same techniques and expect the same
good results, but we don't do that right now.

-- 
Peter Geoghegan



В списке pgsql-bugs по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: BUG #17619: AllocSizeIsValid violation in parallel hash join
Следующее
От: Tom Lane
Дата:
Сообщение: Re: BUG #17619: AllocSizeIsValid violation in parallel hash join