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
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)", |