From fd42262836be6c3fdf77cc0c774964f04acdc913 Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Fri, 28 Mar 2003 20:17:13 +0000 Subject: Add code to apply some simple sanity checks to the header fields of a page when it's read in, per pghackers discussion around 17-Feb. Add a GUC variable zero_damaged_pages that causes the response to be a WARNING followed by zeroing the page, rather than the normal ERROR; this is per Hiroshi's suggestion that there needs to be a way to get at the data in the rest of the table. --- doc/src/sgml/runtime.sgml | 22 ++++++++++++++++++++-- 1 file changed, 20 insertions(+), 2 deletions(-) (limited to 'doc/src') diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml index cc6efab0cfc..18dd9fe4a43 100644 --- a/doc/src/sgml/runtime.sgml +++ b/doc/src/sgml/runtime.sgml @@ -1,5 +1,5 @@ @@ -1599,7 +1599,7 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir' It should be noted that the performance penalty of having - fsync on considerably less in + fsync on is considerably less in PostgreSQL version 7.1 and later. If you previously suppressed fsync for performance reasons, you may wish to reconsider your choice. @@ -2174,6 +2174,24 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir' + + 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 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. + + + + -- cgit v1.2.3