Alvaro Herrera <alvhe...@commandprompt.com> writes: > I'm chasing an apparent index corruption problem, and I came across > something I can't quite explain in pg_filedump. Say I dump a non-leaf > btree index page:
I think this is actually OK. Remember that in a non-rightmost page, item 1 is the high key not a data entry. On the other hand, in a non-leaf page, we don't bother to store the key for the first downlink entry, since the associated key is really "minus infinity". Cf nbtree/README: On a non-leaf page, the data items are down-links to child pages with bounding keys. The key in each data item is the *lower* bound for keys on that child page, so logically the key is to the left of that downlink. The high key (if present) is the upper bound for the last downlink. The first data item on each such page has no lower bound --- or lower bound of minus infinity, if you prefer. The comparison routines must treat it accordingly. The actual key stored in the item is irrelevant, and need not be stored at all. This arrangement corresponds to the fact that an L&Y non-leaf page has one more pointer than key. So item 2 doesn't have a key in it. The other two items have null keys, which means they need a null bitmap. I don't however understand why there seems to be data as well as a null bitmap in there --- is this perhaps a two-column index? > (The "Has Nulls" bit is somewhat bogus -- it displays 32768 when the > 0x8000 bit is on, which is rather surprising. I'd expect it to display > 1). Yeah, I noticed that too. Made a note to myself to fix it in the next revision of pg_filedump, which I suppose I'd better get on with producing... regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers