From: | "Ed L(dot)" <pgsql(at)bluepolka(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Invalid page header |
Date: | 2004-10-21 06:31:15 |
Message-ID: | 200410210031.15480.pgsql@bluepolka.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Jiří Němec | 2004-10-21 07:08:46 | DB modeler |
Previous Message | Katsaros Kwn/nos | 2004-10-21 06:26:30 | Linking question |