Invalid page header

[Ed L.]

I have 5 corrupted page headers as evidenced by these errors:

ERROR: Invalid page header in block 13947 of ...

The corruption is causing numerous queries to abort. First option is to try
to salvage data before attempt restore from backup. I want to try to edit
the file to zero out the bogus headers. I realize there may be data lost
from this attempt. I have scalpel (binary editor) in hand.

Which bytes should I edit, and what do I make them?
$ pg_filedump -if -R 1343 1343 25268878.38650946

************************************************** ***************
* PostgreSQL File/Block Formatted Dump Utility - Version 1.1
*
* File: 25268878.38650946
* Options used: -if -R 1343 1343
*
* Dump created on: Wed Oct 20 19:14:06 2004
************************************************** ***************

Block 1343 ************************************************** ****
<Header> -----
Block Offset: 0x00a7e000 Offsets: Lower 0 (0x0000)
Block: Size 0 Version 0 Upper 0 (0x0000)
LSN: logid 0 recoff 0x00000000 Special 0 (0x0000)
Items: -5 Free Space: 0
Length (including item array): 24

Error: Invalid header information.

0000: 00000000 00000000 00000000 00000000 ................
0010: 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.

*** End of Requested Range Encountered. Last Block Read: 1343 ***
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

[Ed L.]

On Wednesday October 20 2004 5:34, Ed L. wrote:

I have 5 corrupted page headers as evidenced by these errors:

ERROR: Invalid page header in block 13947 of ...

The corruption is causing numerous queries to abort. First option is to
try to salvage data before attempt restore from backup. I want to try to
edit the file to zero out the bogus headers. I realize there may be data
lost from this attempt. I have scalpel (binary editor) in hand.

Which bytes should I edit, and what do I make them?
In other words, how do I calculate which bytes to zero to simulate
zero_damaged_pages??

TIA.



$ pg_filedump -if -R 1343 1343 25268878.38650946

************************************************** ***************
* PostgreSQL File/Block Formatted Dump Utility - Version 1.1
*
* File: 25268878.38650946
* Options used: -if -R 1343 1343
*
* Dump created on: Wed Oct 20 19:14:06 2004
************************************************** ***************

Block 1343 ************************************************** ****
<Header> -----
Block Offset: 0x00a7e000 Offsets: Lower 0 (0x0000)
Block: Size 0 Version 0 Upper 0 (0x0000)
LSN: logid 0 recoff 0x00000000 Special 0 (0x0000)
Items: -5 Free Space: 0
Length (including item array): 24

Error: Invalid header information.

0000: 00000000 00000000 00000000 00000000 ................
0010: 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.

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

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to ma*******@postgresql.org)

[Ed L.]

On Wednesday October 20 2004 10:12, Ed L. wrote:

On Wednesday October 20 2004 10:00, Tom Lane wrote:

"Ed L." <pg***@bluepolka.net> writes:

In other words, how do I calculate which bytes to zero to simulate
zero_damaged_pages??

Why simulate it, when you can just turn it on? But anyway, the answer
is "the whole page".

Old 7.3.4 installation, didn't realize that feature was there. Thx.

That worked for 3 of 4 cases, but for a fourth, I see the message that it's
zeroing the page, but then it continues to report invalid page header for
that block... maybe the header is too fouled up to fix?
Ed
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

[Tom Lane]

"Ed L." <pg***@bluepolka.net> writes:

In other words, how do I calculate which bytes to zero to simulate
zero_damaged_pages??

Why simulate it, when you can just turn it on? But anyway, the answer
is "the whole page".

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings

[Ed L.]

On Wednesday October 20 2004 10:00, Tom Lane wrote:

"Ed L." <pg***@bluepolka.net> writes:

In other words, how do I calculate which bytes to zero to simulate
zero_damaged_pages??

Why simulate it, when you can just turn it on? But anyway, the answer
is "the whole page".

Old 7.3.4 installation, didn't realize that feature was there. Thx.
---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to ma*******@postgresql.org so that your
message can get through to the mailing list cleanly

[Ed L.]

On Wednesday October 20 2004 10:43, Ed L. wrote:

On Wednesday October 20 2004 10:12, Ed L. wrote:

On Wednesday October 20 2004 10:00, Tom Lane wrote:

"Ed L." <pg***@bluepolka.net> writes:
> In other words, how do I calculate which bytes to zero to simulate
> zero_damaged_pages??

Why simulate it, when you can just turn it on? But anyway, the
answer is "the whole page".

Old 7.3.4 installation, didn't realize that feature was there. Thx.

That worked for 3 of 4 cases, but for a fourth, I see the message that
it's zeroing the page, but then it continues to report invalid page
header for that block... maybe the header is too fouled up to fix?

I didn't notice zero_damaged_pages because it doesn't show up by default in
the postgresql.conf file, I guess wisely since it is somewhat dangerous to
the forensic evidence.

I fixed the case that zero_damaged_pages didn't by truncating the file at
the precise byte offset reported by pg_filedump for the bad block via
'pg_filedump -if -R ...'

Ed

---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to ma*******@postgresql.org