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

From Bruce Momjian
Subject Re: Detecting corrupted pages earlier
Date
Msg-id 200304022034.h32KYnQ19987@candle.pha.pa.us
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>)
List pgsql-hackers
Tom Lane wrote:
> Kevin Brown <kevin@sysexperts.com> writes:
> > Tom Lane wrote:
> >> 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...
> 
> Andrew Sullivan expressed concern about this, too.  The thing could
> be made a little more failsafe if we made it impossible to set
> ZERO_DAMAGED_PAGES to true in postgresql.conf, or by any means other
> than an actual SET command --- whose impact would then be limited to
> the current session.  This is kind of an ugly wart on the GUC mechanism,
> but I think not difficult to do with an assign_hook (it just has to
> refuse non-interactive settings).
> 
> Comments?

Perhaps better would be to throw a message message any time it is turned
on, reminding them it should not be left on.  Is that cleaner?

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073
 



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Detecting corrupted pages earlier
Next
From: Tom Lane
Date:
Subject: Re: Detecting corrupted pages earlier