Re: right sibling is not next child
От | Peter Brant |
---|---|
Тема | Re: right sibling is not next child |
Дата | |
Msg-id | 443CE72B020000BE00002CA4@gwmta.wicourts.gov обсуждение исходный текст |
Ответ на | Re: right sibling is not next child ("Peter Brant" <Peter.Brant@wicourts.gov>) |
Ответы |
Re: right sibling is not next child
|
Список | pgsql-bugs |
Per the DBAs, there hadn't been any recent crashes before last Thursday. A "vacuum analyze verbose" discovered the problem early Thursday morning. After the PANIC, the database never came back up (the heap_clean_redo: no block / full_page_writes = off problem). One thing that seems strange to me is that the original crash on Thursday failed on Panel_pkey, but my "vacuum analyze verbose" on a copy of the crashed database failed on MaintCode / pg_statistic_relid_att_index. I'll send over pg_statistic_relid_att_index and Panel_pkey. Showing the keys to Panel_pkey is no problem. Pete >>> Tom Lane <tgl@sss.pgh.pa.us> 04/12/06 6:03 pm >>> 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 по дате отправления: