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:55:57Z
Lists: pgsql-bugs
On Tue, Sep 27, 2022 at 9:44 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > 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). I'd also like to use Valgrind here. That's how I noticed this issue, in fact. I wrote a very rough patch (too rough to even post as an FYI). I don't think that CLOBBER_FREED_MEMORY would necessarily have detected the problems with PARALLEL_KEY_BUFFER_USAGE/PARALLEL_KEY_WAL_USAGE (or the analogous problems in nbtsort.c and vacuumparallel.c). The big advantage of custom Valgrind instrumentation that marks newly allocated memory undefined (not inaccessible) is the provenance stuff. Valgrind will track the provenance of the uninitialized memory reliably, even as the values are copied around. Any control flow that relies on the value will make Valgrind complain. -- 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