Re: BUG #17619: AllocSizeIsValid violation in parallel hash join
Peter Geoghegan <pg@bowt.ie>
From: Peter Geoghegan <pg@bowt.ie>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Thomas Munro <thomas.munro@gmail.com>,
Dmitry Astapov <dastapov@gmail.com>, pgsql-bugs@lists.postgresql.org
Date: 2022-09-27T16:40:05Z
Lists: 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
Commits
-
Fix rare sharedtuplestore.c corruption.
- d95dcc9ab5f8 11.19 landed
- b55303792afe 12.14 landed
- 1a5afe007779 13.10 landed
- 2f65b84683b7 14.7 landed
- d9f5345bf907 15.2 landed
- ffcf6f4cfca5 16.0 landed
-
Initialize index stats during parallel VACUUM.
- 662ba729a67e 16.0 cited
-
Stamp 13.8.
- 4bc493d14409 13.8 cited