| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | James Coleman <jtc331(at)gmail(dot)com> |
| Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Tomas Vondra <tomas(dot)vondra(at)postgresql(dot)org>, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> |
| Subject: | Re: 13dev failed assert: comparetup_index_btree(): ItemPointer values should never be equal |
| Date: | 2020-07-28 15:47:04 |
| Message-ID: | CAH2-WzmTgqv5ThQbjuAuPbJgVscUE3woVOyugwxq2hejnPFLdA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Jul 28, 2020 at 8:40 AM James Coleman <jtc331(at)gmail(dot)com> wrote:
> Is that assumption largely based on the incremental sort patch
> refactoring tuplesort.c a bit? I haven't looked at it much at all, but
> I'm wondering if the issue could also be related to the btree
> duplicates changes in 13 given that we're looking at
> comparetup_index_btree and the datums are equal.
It couldn't possibly be the deduplication patch. That didn't change
anything in tuplesort.c.
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.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fujii Masao | 2020-07-28 17:00:04 | Re: [PATCH] Initial progress reporting for COPY command |
| Previous Message | Justin Pryzby | 2020-07-28 15:45:41 | Re: 13dev failed assert: comparetup_index_btree(): ItemPointer values should never be equal |