Re: 8.1 index corruption woes

From: Decibel! <decibel(at)decibel(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: 8.1 index corruption woes
Date: 2008-07-14 15:20:25
Message-ID: 373E4AE7-8DE0-4663-BFEF-4E833C7AF851@decibel.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Jul 11, 2008, at 2:17 PM, Tom Lane wrote:
> Alvaro Herrera <alvherre(at)commandprompt(dot)com> writes:
>> I don't want to discard this idea, because we're getting a very
>> unusually high number of bogus entries. However, they are all (or a
>> very high percentage of them) the very first entry on each index
>> page.
>> I want to confirm that the leftmost on a leaf btree page is a valid
>> item, and not something like the lower bound value? (I think we only
>> store high bounds on internal pages, not leaf pages, but I'm not
>> sure).
>
> Er ... no. Per nbtree/README:
>
> : On a page that is not rightmost in its tree level, the "high key" is
> : kept in the page's first item, and real data items start at item 2.
> : The link portion of the "high key" item goes unused. A page that is
> : rightmost has no "high key", so data items start with the first
> item.
> : Putting the high key at the left, rather than the right, may seem
> odd,
> : but it avoids moving the high key as we add data items.
>
> (Right offhand, it looks like _bt_split just copies the item that it's
> cloning the index key of. Maybe it would be worth setting the item
> pointer invalid, to prevent confusion in future?)

Another option would be to change pg_filedump to understand what the
first item in the index is.
--
Decibel!, aka Jim C. Nasby, Database Architect decibel(at)decibel(dot)org
Give your computer some brain candy! www.distributed.net Team #1828

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Knight, Doug 2008-07-14 15:21:23 Building under Visual Studio 2008 - pqcomm.c compile error
Previous Message Tom Lane 2008-07-14 14:26:58 Re: PATCH: CITEXT 2.0 v3