Re: BUG #16582: Logical index corruption leading to apparent index scan infinite loop
От | Peter Geoghegan |
---|---|
Тема | Re: BUG #16582: Logical index corruption leading to apparent index scan infinite loop |
Дата | |
Msg-id | CAH2-Wzn0caF5We0Pu8yzrWVYVqbaDrB86X6GemmS-13FvdE8Cg@mail.gmail.com обсуждение исходный текст |
Ответ на | BUG #16582: Logical index corruption leading to apparent index scan infinite loop (PG Bug reporting form <noreply@postgresql.org>) |
Ответы |
Re: BUG #16582: Logical index corruption leading to apparent index scan infinite loop
|
Список | 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 по дате отправления: