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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gavin Sherry <swm(at)linuxworld(dot)com(dot)au>
Cc: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: TRAP: FailedAssertion("!((itemid)->lp_flags & 0x01)", File: "nbtsearch.c", Line: 89)
Date: 2005-10-28 04:44:06
Message-ID: 26726.1130474646@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Gavin Sherry <swm(at)linuxworld(dot)com(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Philip Yarra 2005-10-28 04:55:21 Re: pl/pgsql breakage in 8.1b4?
Previous Message Gavin Sherry 2005-10-28 04:26:31 Re: TRAP: FailedAssertion("!((itemid)->lp_flags & 0x01)",