Re: 3rd time is a charm.....right sibling is not next child crash.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Jeff Amiel <becauseimjeff(at)yahoo(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: 3rd time is a charm.....right sibling is not next child crash.
Date: 2010-08-28 20:11:10
Message-ID: 24253.1283026270@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

Alvaro Herrera <alvherre(at)commandprompt(dot)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: right sibling 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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2010-08-28 20:25:07 Re: two different posgres t for Rails development?
Previous Message Rich Shepard 2010-08-28 19:50:32 Re: two different posgres t for Rails development?

Browse pgsql-hackers by date

  From Date Subject
Next Message Greg Smith 2010-08-28 21:00:31 Re: Interruptible sleeps (was Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!)
Previous Message James William Pye 2010-08-28 18:37:38 Re: [HACKERS] Trouble with COPY IN