Kevin Brown <[EMAIL PROTECTED]> 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...

Here's what I put in --- feel free to suggest better wording.


     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.

                        regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

Reply via email to