pg_filedump strangeness

Alvaro Herrera <alvherre@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

Tom Lane wrote:

Alvaro Herrera <alvherre@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

Tom Lane wrote:

Alvaro Herrera <alvherre@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.

Oh, BTW, this is not what's corrupted about this index -- I just had
trouble following what pg_filedump was reporting. The corruption is
more subtle: vacuum cannot find the parent page when trying to mark a
page for deletion.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.