zero_damaged_pages must absolutely NOT be marked GUC_DISALLOW_IN_FILE,

else it cannot be used to handle failures detected during WAL replay.
Fortunately this flag isn't actually enforced yet, but get it right.

diff --git a/src/backend/utils/misc/guc.c b/src/backend/utils/misc/guc.c
index c3e9a0ec8180224df08c6d82c77e4b8f27995231..197e52517f71d89a201c1895ed059a027bb8816d 100644 (file)
--- a/src/backend/utils/misc/guc.c
+++ b/src/backend/utils/misc/guc.c
@@ -10,7 +10,7 @@
  * Written by Peter Eisentraut <peter_e@gmx.net>.
  *
  * IDENTIFICATION
- *       $Header: /cvsroot/pgsql/src/backend/utils/misc/guc.c,v 1.164 2003/10/18 22:59:09 petere Exp $
+ *       $Header: /cvsroot/pgsql/src/backend/utils/misc/guc.c,v 1.164.2.1 2003/11/07 21:27:50 tgl Exp $
  *
  *--------------------------------------------------------------------
  */
@@ -466,7 +466,7 @@ static struct config_bool ConfigureNamesBool[] =
                                                 "zero_damaged_pages to true 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."),
-                       GUC_NOT_IN_SAMPLE | GUC_DISALLOW_IN_FILE
+                       GUC_NOT_IN_SAMPLE
                },
                &zero_damaged_pages,
                false, NULL, NULL