Re: TRAP: FailedAssertion("!((itemid)->lp_flags & 0x01)", File: "nbtsearch.c", Line: 89) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: TRAP: FailedAssertion("!((itemid)->lp_flags & 0x01)", File: "nbtsearch.c", Line: 89)
Date
Msg-id 26726.1130474646@sss.pgh.pa.us
Whole thread Raw
In response to TRAP: FailedAssertion("!((itemid)->lp_flags & 0x01)", File: "nbtsearch.c", Line: 89)  ("Jim C. Nasby" <jnasby@pervasive.com>)
List pgsql-hackers
Gavin Sherry <swm@linuxworld.com.au> writes:
> Definately. I've seen faulty hardware somehow zero blocks where I would
> have expected random data. I wonder if we can test with PageIsNew(), which
> is very inexpensive. The question is: what do we do when we detect this?

I think erroring out with a message along the line of "corrupted data in
index foo" is plenty.  The recovery action is easy: reindex.  So all we
have to do is not crash and deliver a useful error message.

We know that the page has already gotten by PageHeaderIsValid, so either
it's in reasonable condition or it's all zeroes.  So a quick check for
some nonzero header fields is enough ... PageIsNew is as good as
anything.

The next question is what's the minimal number of places we have to add
it to to cover all paths in the index modules?

> That being said, is there any reason where don't extend the file with a
> PageInit()'d block instead of a zero'd file?

Yeah: this scenario is exactly it.  PageInit doesn't make for a valid
index page.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: TRAP: FailedAssertion("!((itemid)->lp_flags & 0x01)", File: "nbtsearch.c", Line: 89)
Next
From: Philip Yarra
Date:
Subject: Re: pl/pgsql breakage in 8.1b4?