Re: Detecting corrupted pages earlier

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

In response to

Responses

Browse pgsql-hackers by date

  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