Re: BUG #16582: Logical index corruption leading to apparent index scan infinite loop - Mailing list pgsql-bugs

From Peter Geoghegan
Subject Re: BUG #16582: Logical index corruption leading to apparent index scan infinite loop
Date
Msg-id CAH2-Wzn0caF5We0Pu8yzrWVYVqbaDrB86X6GemmS-13FvdE8Cg@mail.gmail.com
Whole thread Raw
In response to BUG #16582: Logical index corruption leading to apparent index scan infinite loop  (PG Bug reporting form <noreply@postgresql.org>)
Responses Re: BUG #16582: Logical index corruption leading to apparent index scan infinite loop  (James Lucas <jlucasdba@gmail.com>)
List pgsql-bugs
On Fri, Aug 14, 2020 at 2:03 PM PG Bug reporting form
<noreply@postgresql.org> wrote:
> The table has two indexes, so I decided to scan both indexes on all
> partitions with the bt_index_check function from the amcheck extension.  I
> identified one partition where both indexes throw the following result:
> ERROR: cross page item order invariant violated for index "xxxxx"
> DETAIL: Last item on page tid(xx,xx) page lsn=xxxxxxxxxx

This sounds very much like an index with sibling pages that are in the
wrong order relative to each other. That's totally consistent with
what you describe with _bt_moveright() -- circular sibling links can
cause it to just keep going.

It's possible that you'll get a better error with
bt_index_parent_check(), which might be worth trying. But it probably
won't give you any additional information.

Note that there is DEBUG1 and DEBUG2 output from amcheck, which might
give you a few more details. You can "set client_min_messages =
'debug2'" in an interactive session that runs bt_index_check() to see
some additional context. Again, this is unlikely to make all that much
difference.

-- 
Peter Geoghegan



pgsql-bugs by date:

Previous
From: PG Bug reporting form
Date:
Subject: BUG #16582: Logical index corruption leading to apparent index scan infinite loop
Next
From: Mukesh Chhatani
Date:
Subject: Logical replication stalling for large tables with heavy write activity - Pg11