Make the 'wal_debug' GUC variable a boolean (rather than an integer), and

hide it behind #ifdef WAL_DEBUG blocks.

doc/src/sgml/ref/show.sgml

@@ -1,5 +1,5 @@
 <!--
-$PostgreSQL: pgsql/doc/src/sgml/ref/show.sgml,v 1.34 2003/11/29 19:51:39 pgsql Exp $
+$PostgreSQL: pgsql/doc/src/sgml/ref/show.sgml,v 1.35 2004/01/06 17:26:23 neilc Exp $
 PostgreSQL documentation
 -->
 
@@ -172,7 +172,7 @@ SHOW ALL;
     .
     .
     .
- wal_debug                     | 0
+ wal_debug                     | off
  wal_sync_method               | fdatasync
 (94 rows)
 </programlisting>

doc/src/sgml/runtime.sgml

@@ -1,5 +1,5 @@
 <!--
-$PostgreSQL: pgsql/doc/src/sgml/runtime.sgml,v 1.228 2004/01/05 20:37:51 neilc Exp $
+$PostgreSQL: pgsql/doc/src/sgml/runtime.sgml,v 1.229 2004/01/06 17:26:22 neilc Exp $
 -->
 
 <Chapter Id="runtime">
@@ -2667,10 +2667,13 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
      </varlistentry>
 
      <varlistentry>
-      <term><varname>wal_debug</varname> (<type>integer</type>)</term>
+      <term><varname>wal_debug</varname> (<type>boolean</type>)</term>
       <listitem>
        <para>
-        If nonzero, turn on WAL-related debugging output.
+        If true, emit WAL-related debugging output. This option is
+        only available if the <symbol>WAL_DEBUG</symbol> macro was
+        defined when <productname>PostgreSQL</productname> was
+        compiled.
        </para>
       </listitem>
      </varlistentry>

doc/src/sgml/wal.sgml

@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/wal.sgml,v 1.26 2003/11/29 19:51:38 pgsql Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/wal.sgml,v 1.27 2004/01/06 17:26:23 neilc Exp $ -->
 
 <chapter id="wal">
  <title>Write-Ahead Logging (<acronym>WAL</acronym>)</title>
@@ -19,10 +19,10 @@
    transaction processing. Briefly, <acronym>WAL</acronym>'s central
    concept is that changes to data files (where tables and indexes
    reside) must be written only after those changes have been logged,
-   that is, when log records have been flushed to permanent
-   storage. If we follow this procedure, we do not need to flush
-   data pages to disk on every transaction commit, because we know
-   that in the event of a crash we will be able to recover the
+   that is, when log records describing the changes have been flushed
+   to permanent storage. If we follow this procedure, we do not need
+   to flush data pages to disk on every transaction commit, because we
+   know that in the event of a crash we will be able to recover the
    database using the log: any changes that have not been applied to
    the data pages will first be redone from the log records (this is
    roll-forward recovery, also known as REDO) and then changes made by
@@ -187,7 +187,7 @@
   <para>
    There will be at least one 16 MB segment file, and will normally
    not be more than 2 * <varname>checkpoint_segments</varname> + 1
-   files.  You can use this to estimate space requirements for WAL.
+   files.  You can use this to estimate space requirements for <acronym>WAL</acronym>.
    Ordinarily, when old log segment files are no longer needed, they
    are recycled (renamed to become the next segments in the numbered
    sequence). If, due to a short-term peak of log output rate, there
@@ -254,7 +254,7 @@
   <para>
    The <varname>wal_sync_method</varname> parameter determines how
    <productname>PostgreSQL</productname> will ask the kernel to force
-    WAL updates out to disk. 
+    <acronym>WAL</acronym> updates out to disk. 
    All the options should be the same as far as reliability goes,
    but it's quite platform-specific which one will be the fastest.
    Note that this parameter is irrelevant if <varname>fsync</varname>
@@ -262,11 +262,10 @@
   </para>
 
   <para>
-   Setting the <varname>wal_debug</varname> parameter to any nonzero
-   value will result in each <function>LogInsert</function> and
+   Enabling the <varname>wal_debug</varname> configuration parameter
+   will result in each <function>LogInsert</function> and
    <function>LogFlush</function> <acronym>WAL</acronym> call being
-   logged to the server log.  At present, it makes no difference what
-   the nonzero value is.  This option may be replaced by a more
+   logged to the server log. This option may be replaced by a more
    general mechanism in the future.
   </para>
  </sect1>