Re: Invalid page header

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 ***

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 ***

"Ed L." <pgsql(at)bluepolka(dot)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

On Wednesday October 20 2004 10:00, Tom Lane wrote:
> "Ed L." <pgsql(at)bluepolka(dot)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.

On Wednesday October 20 2004 10:12, Ed L. wrote:
> On Wednesday October 20 2004 10:00, Tom Lane wrote:
> > "Ed L." <pgsql(at)bluepolka(dot)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

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." <pgsql(at)bluepolka(dot)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