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-27T17:58:09Z
Lists: pgsql-bugs
On Tue, Sep 27, 2022 at 9:40 AM Peter Geoghegan <pg@bowt.ie> wrote: > 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. Actually, it looks like we'll always have each worker zero-initialize their space for buffer stats and WAL stats in InstrEndParallelQuery(), which is also called by nbtsort.c and by parallel VACUUM. So as it turns out there is no issue with uninitialized memory here. I don't think that that changes all that much. It still seems like a good idea to do all required zero initialization in the leader, up front. We're talking about very small structures here, so there is no reason to not have a uniform, centralized approach in ParallelQueryMain(). We actually zero initialized the dead_items array for PARALLEL_VACUUM_KEY_DEAD_ITEMS, which is probably unnecessary and has non-trivial overhead, but we don't zero initialize relatively tiny WAL and buffer instrumentation counters nearby. -- 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