Hi,

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:

*******************************************************************
* PostgreSQL File/Block Formatted Dump Utility - Version 8.3.0
*
* File: 31141
* Options used: -fi -x -R 6246 
*
* Dump created on: Tue Apr  6 17:40:28 2010
*******************************************************************

Block 6246 ********************************************************
<Header> -----
 Block Offset: 0x030cc000         Offsets: Lower      36 (0x0024)
 Block: Size 8192  Version    4            Upper    8120 (0x1fb8)
 LSN:  logid   1077 recoff 0x45c8b660      Special  8176 (0x1ff0)
 Items:    3                      Free Space: 8084
 TLI: 0x0001  Prune XID: 0x00000000  Flags: 0x0000 ()
 Length (including item array): 36

  0000: 35040000 60b6c845 01000000 2400b81f  5...`..E....$...
  0010: f01f0420 00000000 d89f3000 d09f1000  ... ......0.....
  0020: b89f3000                             ..0.            

<Data> ------ 
 Item   1 -- Length:   24  Offset: 8152 (0x1fd8)  Flags: NORMAL
  Block Id: 6232  linp Index: 1  Size: 24
  Has Nulls: 32768  Has Varwidths: 0

  1fd8: 00005818 01001880 01000000 00000000  ..X.............
  1fe8: 80bcc57d 74230100                    ...}t#..        

 Item   2 -- Length:    8  Offset: 8144 (0x1fd0)  Flags: NORMAL
  Block Id: 2756  linp Index: 1  Size: 8
  Has Nulls: 0  Has Varwidths: 0

  1fd0: 0000c40a 01000800                    ........        

 Item   3 -- Length:   24  Offset: 8120 (0x1fb8)  Flags: NORMAL
  Block Id: 6231  linp Index: 1  Size: 24
  Has Nulls: 32768  Has Varwidths: 0

  1fb8: 00005718 01001880 01000000 00000000  ..W.............
  1fc8: 4009cc7f 73230100                    @...s#..        


<Special Section> -----
 BTree Index Section:
  Flags: 0x0000 ()
  Blocks: Previous (6109)  Next (6305)  Level (1)  CycleId (0)

  1ff0: dd170000 a1180000 01000000 00000000  ................


*** End of Requested Range Encountered. Last Block Read: 6246 ***


Notice how item 2 has size 8, but regular entries have size 24.  I know
this is related to the high key of this page, but I can't quite figure
out why the short entry is 2 not 1.  Is item 2 just assumed to be
greater than the previous' page high key?

Page's 6109 high key is:

 Item   1 -- Length:   24  Offset: 8152 (0x1fd8)  Flags: NORMAL
  Block Id: 6101  linp Index: 1  Size: 24
  Has Nulls: 32768  Has Varwidths: 0

  1fd8: 0000d517 01001880 01000000 00000000  ................
  1fe8: 8004f17d 6f230100                    ...}o#..        


Note that the data values are integer timestamp without time zone in
little endian byte order.


(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).


-- 
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

Reply via email to