"L.Boldareva" <pg@pierro.dds.nl> writes:
> LOG: database system was not properly shut down; automatic recovery in
> progress
> LOG: redo starts at 5/6F000ABC
> PANIC: btree_split_redo: lost left sibling
> LOG: startup process (PID 5603) was terminated by signal 6
Hmm. AFAICS that could only happen if a page split record is pointing
at an "original" page that's not there anymore; that is, the page is
past what the kernel says is the end of the file. Exactly how did you
get into this state ... was there a system-level crash involved? ISTM
this cannot happen unless the filesystem has dropped data.
You could probably get it to start by changing the "false" to "true"
in this call of XLogReadBuffer
/* Left (original) sibling */
buffer = XLogReadBuffer(false, reln, leftsib);
if (!BufferIsValid(buffer))
elog(PANIC, "btree_split_%s: lost left sibling", op);
in src/backend/access/nbtree/nbtxlog.c (it's line 261 in CVS tip,
possibly a little different in 8.0). Let us know if that helps.
I'd be a bit suspicious of the contents of the index, if not the
whole database, so an immediate dump,reinitdb,reload might be your
most prudent course of action after you get it to start.
Plan B would be to wipe out the WAL log with pg_resetxlog. This will
allow you to start but the odds of having corrupt data afterwards would
be about 100% ... you *must* dump and reload if you go that way.
regards, tom lane
