pg_filedump strangeness

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: pg_filedump strangeness
Date: 2010-04-06 21:48:47
Message-ID: 20100406214847.GC3491@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2010-04-06 21:52:00 Re: Win32 timezone matching
Previous Message Tom Lane 2010-04-06 21:44:45 Re: Win32 timezone matching