"Jim C. Nasby" <jnasby@pervasive.com> writes:
> On Wed, Oct 26, 2005 at 09:29:23PM -0400, Tom Lane wrote:
>> Could you send me the whole file (off-list)?
> Ok, will send URL as soon as I have it from client.
Well, the answer is that there's nothing wrong with that index except
that four consecutive pages near the end (32K total) have been zeroed
out :-(
In the situation where _bt_search descends into one of these pages,
we'd have the following behavior:
* P_RIGHTMOST() appears true because btpo_next is zero, therefore
_bt_moveright does nothing.
* P_ISLEAF() appears false because the flags word is zero, so we
don't fall out of the loop.
* _bt_binsrch finds high < low and returns low (ie, 1) rather than complaining.
* If Asserts are on then the internal ItemIdIsUsed assert in PageGetItem
triggers, resulting in the behavior mentioned in $subject.
* If not, then we stupidly fetch a zero block number out of the
nonexistent item, and iterate to page zero, ie, the metapage.
The above observations still hold true for the metapage, so
it's an infinite loop --- or would be except that we're building
a stack entry each time around the loop, and so we gradually
exhaust memory. This matches the other behavior Jim saw.
Bottom line is that index searches probably ought to have some
non-Assert defenses against zeroed-out pages. Obviously we can't
expect to catch every flavor of data corruption, but this particular
one has been seen before...
BTW, Jim, any thoughts about how the index got corrupted? Have you
had any crashes on that machine lately?
regards, tom lane