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

From Kevin Brown
Subject Re: Detecting corrupted pages earlier
Date
Msg-id 20030331042456.GI1833@filer
Whole thread Raw
In response to Re: Detecting corrupted pages earlier  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Here's what I put in --- feel free to suggest better wording.
> 
> ZERO_DAMAGED_PAGES (boolean)
> 
>      Detection of a damaged page header normally causes PostgreSQL to
>      report an error, aborting the current transaction. Setting
>      zero_damaged_pages to true causes the system to instead report a
>      warning, zero out the damaged page, and continue processing. This
>      behavior <emphasis>will lose data</>, namely all the rows on the
>      damaged page. But it allows you to get past the error and retrieve
>      rows from any undamaged pages that may be present in the table. So
>      it is useful for recovering data if corruption has occurred due to
>      hardware or software error. The default setting is off, and it can
>      only be changed by a superuser.

I would change "will lose data" to "will destroy data" -- if only to
emphasize the fact that with the option enabled you have no chance of
recoving the data.  Other than that, it looks good to me.

I was going to suggest that perhaps a statement like "running with
this option enabled for normal operation is probably not a good idea"
should be put in there, but whether such a thing belongs in the
documentation or not depends on whether or not you believe the
documentation should be neutral regarding administrative decisions.
The part of the documentation your modification applies to should
probably remain neutral, IMHO, but that implies that perhaps a
paragraph that talks about dealing with damaged pages (and which
references this option) should be placed into the administrator's
guide.



-- 
Kevin Brown                          kevin@sysexperts.com



pgsql-hackers by date:

Previous
From: Kevin Brown
Date:
Subject: Re: Domain breakage
Next
From: "Christopher Kings-Lynne"
Date:
Subject: deadlock problem