Re: right sibling is not next child

"Peter Brant" <Peter(dot)Brant(at)wicourts(dot)gov> writes:
> Item 85 -- Length: 56 Offset: 2120 (0x0848) Flags: USED
> Block Id: 640 linp Index: 1 Size: 56
> Has Nulls: 0 Has Varwidths: 16384

> Item 86 -- Length: 56 Offset: 2176 (0x0880) Flags: USED
> Block Id: 635 linp Index: 1 Size: 56
> Has Nulls: 0 Has Varwidths: 16384

> Item 87 -- Length: 56 Offset: 2232 (0x08b8) Flags: USED
> Block Id: 636 linp Index: 1 Size: 56
> Has Nulls: 0 Has Varwidths: 16384

> Item 88 -- Length: 56 Offset: 2288 (0x08f0) Flags: USED
> Block Id: 635 linp Index: 1 Size: 56
> Has Nulls: 0 Has Varwidths: 16384

> Item 89 -- Length: 56 Offset: 2400 (0x0960) Flags: USED
> Block Id: 629 linp Index: 1 Size: 56
> Has Nulls: 0 Has Varwidths: 16384

> Item 90 -- Length: 56 Offset: 5704 (0x1648) Flags: USED
> Block Id: 166 linp Index: 1 Size: 56
> Has Nulls: 0 Has Varwidths: 16384

Well, that's pretty dang interesting. How did block 635 get to be
listed twice? The sibling links say that the correct sequence is
640, 636, 635, 629, 166 ... so something screwed up the parent level's
keys.

What would be most useful at this point is to look at the keys in
these entries, and compare them to the "high keys" (item 1) of the
individual leaf pages. I'm wondering what key is in that extra
entry for 635 ... Did you get permission to show us the keys?

regards, tom lane