From a385186ff737a935631efd9ff4294588988e67fb Mon Sep 17 00:00:00 2001
From: Tom Lane <tgl@sss.pgh.pa.us>
Date: Thu, 3 Apr 2003 23:32:47 +0000
Subject: Remove zero_damaged_pages from postgresql.conf.sample; the only way
 to find out about it is to read the documentation that tells you how
 dangerous it is.  Add default_transaction_read_only to documentation; seems
 to have been overlooked in patch that added read-only transactions. Clean up
 check_guc comparison script, which has been suffering bit rot.

---
 doc/src/sgml/runtime.sgml | 27 ++++++++++++++++++++++++---
 1 file changed, 24 insertions(+), 3 deletions(-)

(limited to 'doc/src')

diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
index 18dd9fe4a43..131a670b59a 100644
--- a/doc/src/sgml/runtime.sgml
+++ b/doc/src/sgml/runtime.sgml
@@ -1,5 +1,5 @@
 <!--
-$Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.175 2003/03/28 20:17:13 tgl Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/runtime.sgml,v 1.176 2003/04/03 23:32:47 tgl Exp $
 -->
 
 <Chapter Id="runtime">
@@ -1476,6 +1476,25 @@ SET ENABLE_SEQSCAN TO OFF;
       </listitem>
      </varlistentry>
 
+     <varlistentry>
+      <indexterm>
+       <primary>read-only transaction</primary>
+      </indexterm>
+
+      <term><varname>DEFAULT_TRANSACTION_READ_ONLY</varname> (<type>boolean</type>)</term>
+      <listitem>
+       <para>
+        A read-only SQL transaction cannot alter non-temporary tables.
+        This parameter controls the default read-only status of each new
+        transaction. The default is false (read/write).
+       </para>
+
+       <para>
+        Consult <xref linkend="sql-set-transaction"> for more information.
+       </para>
+      </listitem>
+     </varlistentry>
+
      <varlistentry>
       <term><varname>DYNAMIC_LIBRARY_PATH</varname> (<type>string</type>)</term>
       <indexterm><primary>dynamic_library_path</></>
@@ -2182,11 +2201,13 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
         <productname>PostgreSQL</> to report an error, aborting the current
 	transaction.  Setting <varname>zero_damaged_pages</> to true causes
 	the system to instead report a warning, zero out the damaged page,
-	and continue processing.  This behavior <emphasis>will lose data</>,
+	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 may
 	be present in the table.  So it is useful for recovering data if
-	corruption has occurred due to hardware or software error.  The
+	corruption has occurred due to hardware or software error.  You should
+	generally not set this true until you have given up hope of recovering
+	data from the damaged page(s) of a table.  The
 	default setting is off, and it can only be changed by a superuser.
        </para>
       </listitem>
-- 
cgit v1.2.3