From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Kevin Brown <kevin(at)sysexperts(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Detecting corrupted pages earlier |
Date: | 2003-03-30 20:29:08 |
Message-ID: | 6086.1049056148@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Kevin Brown <kevin(at)sysexperts(dot)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...
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2003-03-30 20:32:50 | Re: updateable cursors & visibility |
Previous Message | Alvaro Herrera | 2003-03-30 16:34:41 | Re: CVS head doesn't compile |