Re: BUG #17619: AllocSizeIsValid violation in parallel hash join
Thomas Munro <thomas.munro@gmail.com>
From: Thomas Munro <thomas.munro@gmail.com>
To: dastapov@gmail.com, pgsql-bugs@lists.postgresql.org
Date: 2022-09-22T08:44:01Z
Lists: pgsql-bugs
On Thu, Sep 22, 2022 at 7:46 PM PG Bug reporting form <noreply@postgresql.org> wrote: > (gdb) p size > $2 = 1702125924 Thanks for the detailed report. Hmm. That size, on a little-endian system, is equivalent to the byte sequence "date\0\0\0\0", which looks pretty suspiciously like the inside of a tuple, and not its size. We must have got out of sync somehow. > Potentially interesting piece of the puzzle is that there are some long > outliers in rhs.payload and rhs.source, but the rest of the columns have > values that are exactly of avg_width bytes: > > # select log_len, count(*) from (select log(length(payload))::int as log_len > from rhs) foo group by 1 order by 2 desc; > log_len │ count > ─────────┼──────── > 3 │ 840852 > 4 │ 77776 > 5 │ 8003 > 6 │ 1317 > 7 │ 20 > (5 rows) So there are some strings up to order 10^7 in length in there. The file format consists of chunks, with a special case for tuples that don't fit in one chunk. Perhaps there is a bug in that logic. It is exercised in our regression tests, but perhaps not enough. I'll try to repro this from your clues.
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