Tom Lane wrote: > 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.
Ahh, I had forgotten that bit completely. Thanks. > So item 2 doesn't have a key in it. The other two items have null > keys, which means they need a null bitmap. Correct. > 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? Eh, yeah, it's a two column index, so it's OK. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
