Re: BUG #17245: Index corruption involving deduplicated entries
От | Peter Geoghegan |
---|---|
Тема | Re: BUG #17245: Index corruption involving deduplicated entries |
Дата | |
Msg-id | CAH2-WzmLapjJXL4ZNhJJYsbmUUGFJq5Jt2owkUDJhRWXehrgyQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #17245: Index corruption involving deduplicated entries ("K. R." <iijima.yun@koumakan.jp>) |
Ответы |
Re: BUG #17245: Index corruption involving deduplicated entries
|
Список | pgsql-bugs |
On Mon, Oct 25, 2021 at 2:08 PM K. R. <iijima.yun@koumakan.jp> wrote: > There have been no crashes since; there was one reload (pg_hba.conf > edits) and several restarts (to snapshot the file structure with the > corrupted index, plus another enabling WAL archiving today in the morning). Thank you for your help. I wonder if you can show me a page that amcheck reports as having an incorrect posting list? I am interested in posting list tuples that are not just pointing to the wrong thing, but actually look wrong without even looking at the heap. You must have done this for Andrew already, but note that the procedure is outlined here: https://wiki.postgresql.org/wiki/Getting_a_stack_trace_of_a_running_PostgreSQL_backend_on_Linux/BSD#contrib.2Fpageinspect_page_dump For example, the amcheck error with "DETAIL: Index tid=(14,9) posting list offset=110 page lsn=2/2C4F7CD8 btree index "azurlane_wiki.mediawiki.page_len" has an "index TID" of 14, meaning that the block number 14 from the index "azurlane_wiki.mediawiki.page_len" is interesting to me. It could help me with debugging. I can treat this page image as confidential. You could send it to me privately. Thanks again -- Peter Geoghegan
В списке pgsql-bugs по дате отправления: