Re: Detecting corrupted pages earlier

From: Kevin Brown <kevin(at)sysexperts(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Detecting corrupted pages earlier
Date: 2003-03-31 04:24:56
Message-ID: 20030331042456.GI1833@filer
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)sysexperts(dot)com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Neil Conway 2003-03-31 05:55:08 Re: Bug #928: server_min_messages (log_min_messages in CVS)
Previous Message Christopher Kings-Lynne 2003-03-31 03:25:13 deadlock problem