Thread: trying to repair a bad header block
Hi all. I've seen this searching in google. After a select on a table, i got this: ERROR: invalid page header in block 399 of relation "xxx" I read about a tool called pg_filedump, and after some searchs about its usage, i execute pg_filedump $PG_DATA/base/xx/1234 (1234 is the oid of table xxx) As expected, i found the "Invalid header information" in block 399. Lots of this things inside: Block 399 ******************************************************** <Header> -----Block Offset: 0x0031e000 Offsets: Lower 1663 (0x067f)Block: Size 0 Version 95 Upper 0 (0x0000)LSN: logid 5714531 recoff 0x000000e0 Special 60660 (0xecf4)Items: 410 FreeSpace: 4294965633Length (including item array): 1660 Error: Invalid header information. <Data> ------Item 1 -- Length: 0 Offset: 2600 (0x0a28) Flags: 0x00Item 2 -- Length: 0 Offset: 0 (0x0000) Flags: 0x00Item 3 -- Length: 0 Offset: 0 (0x0000) Flags: 0x00Item 4 -- Length: 0 Offset: 0 (0x0000) Flags: 0x00Item 5 -- Length: 32767 Offset: 32767 (0x7fff) Flags: USED Error: Item contents extend beyond block. BlockSize<8192> Bytes Read<8192> Item Start<65534>. This for several items. Im triyng to 'repair' those items in any way, so i can dump the database and analyze the hardware. There is a way to 'correct' or blank the values somehow? I guess im going to lose some data, iisnt... Any hints? Gerardo
gherzig@fmed.uba.ar writes:
> There is a way to 'correct' or blank the values somehow? I guess im going
> to lose some data, iisnt...
If you can tolerate losing the data on that page, just zero out the
entire 8K page. dd from /dev/zero is the usual tool.
regards, tom lane
On Wed, Oct 29, 2008 at 4:23 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > gherzig@fmed.uba.ar writes: >> There is a way to 'correct' or blank the values somehow? I guess im going >> to lose some data, iisnt... > > If you can tolerate losing the data on that page, just zero out the > entire 8K page. dd from /dev/zero is the usual tool. Would zero_damaged_pages work here? I know it's a shotgun to kill a flea, but it's also easier and safer for a lot of folks than dding a page in their table.
"Scott Marlowe" <scott.marlowe@gmail.com> writes:
> On Wed, Oct 29, 2008 at 4:23 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> If you can tolerate losing the data on that page, just zero out the
>> entire 8K page. dd from /dev/zero is the usual tool.
> Would zero_damaged_pages work here? I know it's a shotgun to kill a
> flea, but it's also easier and safer for a lot of folks than dding a
> page in their table.
It would work, but if you have any *other* damaged pages you might
lose more than you were expecting ...
regards, tom lane
On Wed, Oct 29, 2008 at 6:36 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > "Scott Marlowe" <scott.marlowe@gmail.com> writes: >> On Wed, Oct 29, 2008 at 4:23 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> If you can tolerate losing the data on that page, just zero out the >>> entire 8K page. dd from /dev/zero is the usual tool. > >> Would zero_damaged_pages work here? I know it's a shotgun to kill a >> flea, but it's also easier and safer for a lot of folks than dding a >> page in their table. > > It would work, but if you have any *other* damaged pages you might > lose more than you were expecting ... Agreed. OTOH, on slip of the fingers for a newbie with dd and the whole table is gone. I guess it's always a trade off.
On Wed, Oct 29, 2008 at 7:24 PM, Scott Marlowe <scott.marlowe@gmail.com> wrote: Oh, and to reply to myself and the original poster, you need to figure out what's causing the pages to get damaged. IT's usually bad hardware, then a buggy driver, then a buggy kernel / OS that can cause it. Run lots of tests.
> On Wed, Oct 29, 2008 at 6:36 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> "Scott Marlowe" <scott.marlowe@gmail.com> writes: >>> On Wed, Oct 29, 2008 at 4:23 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>>> If you can tolerate losing the data on that page, just zero out the >>>> entire 8K page. dd from /dev/zero is the usual tool. >> >>> Would zero_damaged_pages work here? I know it's a shotgun to kill a >>> flea, but it's also easier and safer for a lot of folks than dding a >>> page in their table. >> >> It would work, but if you have any *other* damaged pages you might >> lose more than you were expecting ... > > Agreed. OTOH, on slip of the fingers for a newbie with dd and the > whole table is gone. I guess it's always a trade off. > > Thanks Tom and Scott! I just use dd for simply creating big files (oh, and once to screw up a entire disk :) Im going to man it in order to zero out that page(s). Wish me lucks, dudes. Thanks! Gerardo
> On Wed, Oct 29, 2008 at 7:24 PM, Scott Marlowe <scott.marlowe@gmail.com> > wrote: > > Oh, and to reply to myself and the original poster, you need to figure > out what's causing the pages to get damaged. IT's usually bad > hardware, then a buggy driver, then a buggy kernel / OS that can cause > it. Run lots of tests. > Oh yes, im facing hw problems. All im triyng to do now is 'rebuild' the header blocks in order to do some pg_dump (whichs is failing, off course), set a new machine and get the actual one to the pits :) Thanks again! Gerardo