Re: right sibling is not next child
От | Tom Lane |
---|---|
Тема | Re: right sibling is not next child |
Дата | |
Msg-id | 29672.1144857792@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: right sibling is not next child ("Peter Brant" <Peter.Brant@wicourts.gov>) |
Список | pgsql-bugs |
"Peter Brant" <Peter.Brant@wicourts.gov> writes: > I can't find any duplicates?!? Weirder and weirder. Maybe the table is OK but the index is corrupt? Could it be another symptom of the same problem we're seeing in the Panel_pkey index? I'm currently theorizing that that index might've been corrupted during WAL replay (specifically, if the replayer somehow failed to recognize a split completion, btree_xlog_cleanup would've inserted an extra entry) and one could certainly imagine multiple indexes getting corrupted in the same fashion at the same time. You did say that this problem showed up shortly after a database crash, right? Could you send me a copy of pg_statistic_relid_att_index, off-list (the actual disk file, not a pg_filedump)? There's nothing but table OIDs and attribute numbers in it, so I can't see any reason anyone would consider it sensitive data. I've got some really crude code laying about for scanning an index and looking for inconsistencies ... it's too ugly to give out, but I'd like to see if it can find anything wrong with that index. (I'll probably ask for a copy of Panel_pkey for the same purpose, if you get permission to show us its keys.) regards, tom lane
В списке pgsql-bugs по дате отправления: