Re: BUG #17619: AllocSizeIsValid violation in parallel hash join
Thomas Munro <thomas.munro@gmail.com>
From: Thomas Munro <thomas.munro@gmail.com>
To: Dmitry Astapov <dastapov@gmail.com>
Cc: pgsql-bugs@lists.postgresql.org
Date: 2022-09-23T23:00:00Z
Lists: pgsql-bugs
Attachments
- 0001-Simple-test-for-sharedtuplestore.c.patch (text/x-patch) patch 0001
- 0002-Fix-sharedtuplestore.c-corruption.patch (text/x-patch) patch 0002
On Fri, Sep 23, 2022 at 4:38 AM Dmitry Astapov <dastapov@gmail.com> wrote: >> I think >= on line 342 should be just > . I tried this change locally, and it fixed the issue for me. >> >> Do you agree with my analysis? Yeah. It was hard to repro the problem from SQL, so I wrote a C module to show the issue. CREATE EXTENSION test_sts; SELECT test_sts(10, 32756); shows it, and is fixed by your proposed change. I will look at the analysis and fix some more next week, and see if the test can be improved some more and is worth keeping. While testing with that module I found another bug: the per-participant npages counter was not explicitly initialised to zero in sts_initialize(). That wasn't exactly a problem when the code was written because new DSM memory is always zeroed and this always happens in new DSM memory, but it shows up in this test module because it uses palloc() memory instead. It *is* a problem since v14, if you use min_dynamic_shared_memory for a pool of recyclable shared memory, because then it is not zeroed.
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