Re: [GENERAL] 3rd time is a charm.....right sibling is not next child crash.
От | Tom Lane |
---|---|
Тема | Re: [GENERAL] 3rd time is a charm.....right sibling is not next child crash. |
Дата | |
Msg-id | 24253.1283026270@sss.pgh.pa.us обсуждение исходный текст |
Ответы |
Re: [GENERAL] 3rd time is a charm.....right sibling is not next child crash.
|
Список | pgsql-hackers |
Alvaro Herrera <alvherre@commandprompt.com> writes: > Excerpts from Jeff Amiel's message of mar jun 08 09:26:25 -0400 2010: >> Jun 7 15:05:01 db-1 postgres[9334]: [ID 748848 local0.crit] [3989781-1] 2010-06-07 15:05:01.087 CDT 9334PANIC: rightsibling 169 of block 168 is not next child of 249 in index "sl_seqlog_idx" > I've seen this problem (and others) in a high-load environment. Not > Slony related though. > I wrote a small tool to check btree index files for consistency problems > such as this one, by parsing pg_filedump output. I've seen strange > things such as index pointers pointing to pages that shouldn't have been > pointed to; mismatching sibling pointers; and others. I spent some more time today looking for possible causes of this (within our code that is; the obvious elephant in the room is the possibility of the disk storage system losing an update). I didn't find anything, but it did occur to me that there is a simple way to ameliorate this problem: we could rearrange the code in _bt_pagedel() so it checks for this case before entering its critical section. Then, corruption of this kind is at least only an ERROR not a PANIC. Any objections to doing that? regards, tom lane
В списке pgsql-hackers по дате отправления: