On Tue, Jul 28, 2020 at 8:47 AM Peter Geoghegan <pg@bowt.ie> wrote:
> This is very likely to be related to incremental sort because it's a
> use-after-free issue, which is the kind of thing that could only
> really happen inside tuplesort.c. This is clear because some of the
> variables have the tell-tale 0x7f7f7f pattern that we written by
> CLOBBER_FREED_MEMORY builds when memory is freed.
Actually, I changed my mind. The pointer variable sortKey within
comparetup_index_btree() has just been incremented in a way that makes
it point past the end of allocated memory, without being dereferenced.
That part is fine.
I still don't think that it's deduplication, though, because at the
point of the crash we haven't even reached _bt_load() yet. That is, we
haven't reached nbtsort.c code that is specific to Postgres 13 yet
(and besides, catalog indexes don't use deduplication in practice).
I wrote the assertion that fails here with the bug that I fixed in
commit 4974d7f87e62a58e80c6524e49677cb25cc10e12 in mind specifically.
That was a bug that involved a scan that returned duplicate tuples due
to a problem in heapam_index_build_range_scan() or all of the
infrastructure that it depends on (directly and indirectly). I wonder
if it's something like that -- this is also a system catalog index.
--
Peter Geoghegan