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@mglenn.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
>
>
>
>