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 majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly

On Wednesday October 20 2004 5:34, Ed L. wrote:
In other words, how do I calculate which bytes to zero to simulate
zero_damaged_pages??

TIA.



---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo (AT) postgresql (DOT) org)

"Ed L." <pgsql (AT) bluepolka (DOT) net> writes:
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

On Wednesday October 20 2004 10:00, Tom Lane wrote:
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 majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly

On Wednesday October 20 2004 10:12, Ed L. wrote:
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 majordomo (AT) postgresql (DOT) org so that your
message can get through to the mailing list cleanly

On Wednesday October 20 2004 10:43, Ed L. wrote:
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 majordomo (AT) postgresql (DOT) org