Re: BUG #15597: possible bug in amcheck/amcheck_next (or corrupted index?)

Peter Geoghegan <pg@bowt.ie>

From: Peter Geoghegan <pg@bowt.ie>
To: "Dr. Andreas Kunert" <kunert@cms.hu-berlin.de>, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2019-01-25T17:57:59Z
Lists: pgsql-bugs
On Thu, Jan 17, 2019 at 6:00 AM PG Bug reporting form
<noreply@postgresql.org> wrote:
> select bt_index_check(12345, true);
> -- result: ERROR:  heap tuple (0,2) from table "foo" lacks matching index
> tuple within index "i_foo"
>
> Despite the error message I suspect the index being ok since I can find the
> aforementioned tuples by using it:
>
> explain select * from foo where b='b' and c='c'
> -- result: Index Scan using i_foo on foo...
> select * from foo where b='b' and c='c'
> -- result: 2 rows

This looks like the same bug that I'm currently working through here:

https://postgr.es/m/CAH2-WznrVd9ie+TTJ45nDT+v2nUt6YJwQrT9SebCdQKtAvfPZw@mail.gmail.com

I have a draft patch that fixes this, but I haven't quite decided if I
want to commit to the approach I've taken to normalizing TOASTed
tuples. I will definitely fix the externally maintained version
(amcheck_next) once this is settled. Thanks for the report.

--
Peter Geoghegan


Commits

  1. Avoid amcheck inline compression false positives.