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
-
Avoid amcheck inline compression false positives.
- eba775345d23 12.0 landed
- 2f541666683b 11.2 landed