Re: right sibling is not next child

"Peter Brant" <Peter(dot)Brant(at)wicourts(dot)gov> writes:
> (a bunch of these)
> [2006-03-31 13:00:01.720 ] 2636 LOG: could not fsync segment 0 of
> relation 1663/16385/1392439: Permission denied
> [2006-03-31 13:00:01.720 ] 2636 ERROR: storage sync failed on magnetic
> disk: Permission denied

Yoi. I think we have seen this (ie, bogus "permission denied" write
errors) happen before on Windows, but no one's quite figured out why.
How many is "a bunch", and what time period did they continue over?
(I think you probably would have gotten one per attempted checkpoint,
but want to confirm.) Did they persist up till that first database
crash at 14:31? What was the immediate cause of the crash (I'm
expecting a PANIC or possibly an Assert triggered it)?

BTW, what sort of filesystem is the database sitting on, on this machine?

> [2006-03-31 14:50:54.828 ] 4052 WARNING: relation "DbTranImageStatus"
> page 130 is uninitialized --- fixing

I'd like to think that all of these are accounted for by the "permission
denied" write failures, but it's hard to tell unless you have log
entries for permission failures on all of their OIDs. (BTW, PG would
probably still have recovered from that, if not for the full_page_writes
= off bug.)

> [2006-03-31 14:50:55.000 ] 4052 PANIC: right sibling is not next child
> in "DbTranImageStatus_pkey" (as part of an autovacuum)

Hmph. So there are (at least) two occurrences of this in the DB.
Does that index contain any sensitive data, and if not could I trouble
you for a copy? I'm still not clear on the mechanism by which the
indexes got corrupted like this. It's starting to look like there may
have been some system-level misfeasance involved, but I'd still like
to understand it in more detail.

regards, tom lane