From 7106f74e2a6feb31c022dd98e7d93ab656dc079d Mon Sep 17 00:00:00 2001 From: Bruce Momjian Date: Tue, 1 Feb 2011 16:43:51 -0500 Subject: [PATCH] Clarify documentation to state that "zero_damaged_pages" does not force data to disk, so the table or index should be recreated before the parameter is turned off again. --- doc/src/sgml/config.sgml | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index 3a0f755b08..141430c56d 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -6059,15 +6059,17 @@ LOG: CleanUpLock: deleting: lock(0xb7acd844) id(24688,24696,0,0,0,1) Detection of a damaged page header normally causes PostgreSQL to report an error, aborting the current - command. Setting zero_damaged_pages to on causes - the system to instead report a warning, zero out the damaged page, - and continue processing. This behavior will destroy data, - namely all the rows on the damaged page. But it allows you to get + transaction. Setting 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 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. So it is useful for recovering data if + 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. The + 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 off, and it can only be changed by a superuser. -- 2.40.0