Re: 8.1 index corruption woes - Mailing list pgsql-hackers

From Tom Lane
Subject Re: 8.1 index corruption woes
Date
Msg-id 18902.1215803828@sss.pgh.pa.us
Whole thread Raw
In response to Re: 8.1 index corruption woes  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: 8.1 index corruption woes  (Decibel! <decibel@decibel.org>)
List pgsql-hackers
Alvaro Herrera <alvherre@commandprompt.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?)
        regards, tom lane


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: 8.1 index corruption woes
Next
From: Tom Lane
Date:
Subject: Re: _bt_delitems: change before WAL?