| 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: | Whole Thread | Raw Message | 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 |