Re: 8.1 index corruption woes
От | Decibel! |
---|---|
Тема | Re: 8.1 index corruption woes |
Дата | |
Msg-id | 373E4AE7-8DE0-4663-BFEF-4E833C7AF851@decibel.org обсуждение исходный текст |
Ответ на | Re: 8.1 index corruption woes (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Jul 11, 2008, at 2:17 PM, Tom Lane wrote: > 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?) 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@decibel.org Give your computer some brain candy! www.distributed.net Team #1828
В списке pgsql-hackers по дате отправления: