Re: zero_damaged_pages doesn't work - Mailing list pgsql-general

From Bruce Momjian
Subject Re: zero_damaged_pages doesn't work
Date
Msg-id 201102012144.p11Lipj17478@momjian.us
Whole thread Raw
In response to Re: zero_damaged_pages doesn't work  (David Boreham <david_list@boreham.org>)
List pgsql-general
David Boreham wrote:
>   On 9/27/2010 4:53 PM, Tom Lane wrote:
> > The reason it tells you that data will be destroyed is that that could
> > very well happen.
>
> Re-parsing this, I think there was a mis-communication :
>
> I'm not at all suggesting that the doc should _not_ say that data will
> be corrupted.
> I'm suggesting that in addition to what it currently says, it also
> should say that the on-disk data won't be
> changed by the page zeroing mode.
>
> In my searching I found countless people over the past few years who had
> been similarly confused into believing that it would write back the
> zeroed page
> to disk.

Based on this discussion from September, I have applied the attached
documentation patch to clarify that zero_damaged_pages are not forced to
disk, and when to set this parameter off again.

--
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

  + It's impossible for everything to be true. +
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 3a0f755..141430c 100644
*** a/doc/src/sgml/config.sgml
--- b/doc/src/sgml/config.sgml
*************** LOG:  CleanUpLock: deleting: lock(0xb7ac
*** 6059,6073 ****
         <para>
          Detection of a damaged page header normally causes
          <productname>PostgreSQL</> to report an error, aborting the current
!         command.  Setting <varname>zero_damaged_pages</> to on causes
!         the system to instead report a warning, zero out the damaged page,
!         and continue processing.  This behavior <emphasis>will destroy 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 might
!         be present in the table.  So it is useful for recovering data if
          corruption has occurred due to a hardware or software error.  You should
          generally not set this on until you have given up hope of recovering
!         data from the damaged pages of a table.  The
          default setting is <literal>off</>, and it can only be changed
          by a superuser.
         </para>
--- 6059,6075 ----
         <para>
          Detection of a damaged page header normally causes
          <productname>PostgreSQL</> to report an error, aborting the current
!         transaction.  Setting <varname>zero_damaged_pages</> to on causes
!         the system to instead report a warning, zero out the damaged
!         page in memory, and continue processing.  This behavior <emphasis>will destroy data</>,
!         namely all the rows on the damaged page.  However, it does allow you to get
          past the error and retrieve rows from any undamaged pages that might
!         be present in the table.  It is useful for recovering data if
          corruption has occurred due to a hardware or software error.  You should
          generally not set this on until you have given up hope of recovering
!         data from the damaged pages of a table.  Zerod-out pages are not
!         forced to disk so it is recommended to recreate the table or
!         the index before turning this parameter off again.  The
          default setting is <literal>off</>, and it can only be changed
          by a superuser.
         </para>

pgsql-general by date:

Previous
From: Alban Hertroys
Date:
Subject: Re: Issues with generate_series using integer boundaries
Next
From: "David Johnston"
Date:
Subject: Windows to Linux PostgreSQL Migration