Re: BUG #17619: AllocSizeIsValid violation in parallel hash join
От | Tom Lane |
---|---|
Тема | Re: BUG #17619: AllocSizeIsValid violation in parallel hash join |
Дата | |
Msg-id | 3802603.1664297080@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #17619: AllocSizeIsValid violation in parallel hash join (PG Bug reporting form <noreply@postgresql.org>) |
Ответы |
Re: BUG #17619: AllocSizeIsValid violation in parallel hash join
Re: BUG #17619: AllocSizeIsValid violation in parallel hash join |
Список | pgsql-bugs |
Peter Geoghegan <pg@bowt.ie> writes: > On Tue, Sep 27, 2022 at 9:24 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> 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. Right, the missing piece is the intentional clobber. Thomas indicated he'd made such a test locally, but I think it needs full support with the same options that mcxt.c has (CLOBBER_FREED_MEMORY and so on --- although unmapping the memory is equally good for that, if we always do it). regards, tom lane
В списке pgsql-bugs по дате отправления: