Re: Database 'xxxx', OID yyyyy, has disappeared from pg_database

I downloaded pg_dumpfile (thank you) then eventually found out I need to
download, configure, and point to 7.2.1 source to compile, which makes
sense now.

I compiled and attempted a dump with the references and without the
references to LSN from the function FormatHeader. In both cases I
received the dump output below indicating "Invalid header
information.". Now, is each block header corrupted OR is the dump
utility not able to read older pg_database files? If switched both
blockOptions and BLOCK_FORMAT to true (1 and 0x00000001 respectively) to
print the raw data anyway. The first part is below. I have no idea how
to interpret the information, perhaps somone else does. If you would
like the entire dump please let me know.

Thanks.

*****************************************************************
* PostgreSQL File/Block Formatted Dump Utility
*
* File: /var/lib/pgsql/pg_database
* Options used: None
*
* Dump created on: Thu Apr 25 13:37:24 2002
*****************************************************************

Block 0 ******************************************************
<Header> -----
Block Offset: 0x00000000 Offsets: Lower 40780 (0x9f4c)
Block Size: 166 Upper 178 (0x00b2)
Special 40696 (0x9ef8)
Items: 10190 Free Space: 4294926694
Length (including item array): 166

Error: Invalid header information.

Error: End of block encountered within the header. Bytes read: 166.

00000000: a0002013 00200020 a89faa00 4c9fb200 .. .. . ....L...
00000010: f89ea600 a89ea000 549ea200 f89db400 ........T.......
00000020: a49da400 549da000 f09ab200 989aae00 ....T...........
00000030: fc9caa00 a89ca800 449aa400 509cae00 ........D...P...
00000040: f89baa00 f099a800 a49ba800 4c9bae00 ............L...
00000050: 9c99a600 4899a200 f098ae00 9898aa00 ....H...........
00000060: 3c98b200 e897a400 9497a400 3c97b000 <...........<...
00000070: e896a800 8c96b400 3896a400 e095b000 ........8.......
00000080: 8895ac00 2c95b800 d094b800 7494b800 ....,.......t...
00000090: 1c94aa00 c893a800 7493a800 2093a800 ........t... ...
000000a0: 00000000 0000 ......

Block 1 ******************************************************
<Header> -----
Block Offset: 0x000000a6 Offsets: Lower 0 (0x0000)
Block Size: 0 Upper 0 (0x0000)
Special 0 (0x0000)
Items: -5 Free Space: 0
Length (including item array): 24

Error: Invalid header information.

000000a6: 00000000 00000000 00000000 00000000 ................
000000b6: 00000000 00000000 ........

<Data> ------
Error: Item index corrupt on block. Offset: <-5>.

<Special Section> -----
Error: Invalid special section encountered.
Error: Special section points off page. Unable to dump contents.

Block 2 ******************************************************
<Header> -----
Block Offset: 0x0000014c Offsets: Lower 0 (0x0000)
Block Size: 0 Upper 0 (0x0000)
Special 0 (0x0000)
Items: -5 Free Space: 0
Length (including item array): 24

Error: Invalid header information.

0000014c: 00000000 00000000 00000000 00000000 ................
0000015c: 00000000 00000000 ........

<Data> ------
Error: Item index corrupt on block. Offset: <-5>.

<Special Section> -----
Error: Invalid special section encountered.
Error: Special section points off page. Unable to dump contents.
.
etc...
.
.

Tom Lane wrote:

>Michael Glenn <mike(at)mglenn(dot)com> writes:
>
>
>>The log is only 98K.
>>
>>
>
>Okay, then you haven't executed four billion transactions...
>
>Probably the next thing is to look at pg_database and try to understand
>why all the rows are showing as dead. There are a couple of tools
>around that can dump out the contents of tuple headers. I'd suggest
>pg_filedump (http://sources.redhat.com/rhdb/tools.html) but it is
>intended for 7.1/7.2 and you'd need to do a little surgery to make it
>work on 7.0 files. (I think ripping out the code that expects an LSN
>field to be present in the page header would be enough.) If you check
>the PG list archives you will find references to one or two older
>programs in the same vein; there might still be something available
>that will work on 7.0 files without modification.
>
> regards, tom lane
>
>---------------------------(end of broadcast)---------------------------
>TIP 4: Don't 'kill -9' the postmaster
>
>
>
>