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 <[email protected]> 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>
--
Sent via pgsql-general mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
