| 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 17:37:13 |
| Message-ID: | CAH2-Wzm-EYh7rxJpPnP3cViw6QLqhZ16ypAF1-H+U=cx6-9O=A@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Jul 28, 2020 at 10:06 AM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> 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.
It's starting to look more like that. I can reproduce the bug by
running the REINDEX in a tight loop while "make installcheck" runs. It
looks as if the two tuples passed to comparetup_index_btree() are
separate tuples that each point to the same heap TID.
I have an rr recording of this. It shouldn't take too long to figure
out what's going on...
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | a.pervushina | 2020-07-28 17:46:04 | psql: add \si, \sm, \st and \sr functions to show CREATE commands for indexes, matviews, triggers and tables |
| Previous Message | Peter Geoghegan | 2020-07-28 17:06:03 | Re: 13dev failed assert: comparetup_index_btree(): ItemPointer values should never be equal |