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 [EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
