Re: Detecting corrupted pages earlier - Mailing list pgsql-hackers

From Kevin Brown
Subject Re: Detecting corrupted pages earlier
Date
Msg-id 20030329115520.GH1833@filer
Whole thread Raw
In response to Re: Detecting corrupted pages earlier  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Detecting corrupted pages earlier  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Detecting corrupted pages earlier  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Kris Jurka <books@ejurka.com> writes:
> > Is zeroing the pages the only / best option?
> 
> It's the only way to avoid a core dump when the system tries to process
> the page.  And no, I don't want to propagate the notion that "this page
> is broken" beyond the buffer manager, so testing elsewhere isn't an
> acceptable answer.
> 
> Basically, one should only turn this variable on after giving up on the
> possibility of getting any data out of the broken page itself.  It would
> be folly to run with it turned on as a normal setting.

This statement should *definitely* go into the documentation for the
option, then...


-- 
Kevin Brown                          kevin@sysexperts.com



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: PostgreSQL and SOAP, version 7.4/8.0
Next
From: Peter Eisentraut
Date:
Subject: SQL/XML examples