On Tue, Jul 28, 2020 at 8:47 AM Peter Geoghegan <p...@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
