Update docs as to when WAL logging can be skipped.

robertmhaas · robertmhaas · commit ee7769bb7649 · 2010-04-20T00:26:06.000Z
In 8.4 and prior, WAL-logging could potentially be skipped whenever
archive_mode=off.  With streaming replication, this is now true only
if max_wal_senders=0.

Fujii Masao, with light copyediting by me
diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml
@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.151 2010/04/12 19:08:28 momjian Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.152 2010/04/20 00:26:06 rhaas Exp $ -->
 
 <chapter id="backup">
  <title>Backup and Restore</title>
@@ -689,13 +689,14 @@ archive_command = 'test ! -f /mnt/server/archivedir/%f &amp;&amp; cp %p /mnt/ser
    </para>
 
    <para>
-    When <varname>archive_mode</> is <literal>off</> some SQL commands
+    When <varname>archive_mode</> is <literal>off</> and <xref
+    linkend="guc-max-wal-senders"> is zero some SQL commands
     are optimized to avoid WAL logging, as described in <xref
-    linkend="populate-pitr">. If archiving were turned on during execution
-    of one of these statements, WAL would not contain enough information
-    for archive recovery.  (Crash recovery is unaffected.)  For
-    this reason, <varname>archive_mode</> can only be changed at server
-    start.  However, <varname>archive_command</> can be changed with a
+    linkend="populate-pitr">.  If archiving or streaming replication were
+    turned on during execution of one of these statements, WAL would not
+    contain enough information for archive recovery.  (Crash recovery is
+    unaffected.)  For this reason, these parameters can only be changed at
+    server start.  However, <varname>archive_command</> can be changed with a
     configuration file reload.  If you wish to temporarily stop archiving,
     one way to do it is to set <varname>archive_command</> to the empty
     string (<literal>''</>).
diff --git a/doc/src/sgml/perform.sgml b/doc/src/sgml/perform.sgml
@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/perform.sgml,v 1.75 2010/04/03 07:22:55 petere Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/perform.sgml,v 1.76 2010/04/20 00:26:06 rhaas Exp $ -->
 
  <chapter id="performance-tips">
   <title>Performance Tips</title>
@@ -910,24 +910,28 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse;
   </sect2>
 
   <sect2 id="populate-pitr">
-   <title>Turn off <varname>archive_mode</varname></title>
+   <title>Turn off <varname>archive_mode</varname> and streaming replication</title>
 
    <para>
     When loading large amounts of data into an installation that uses
-    WAL archiving, you might want to disable archiving (turn off the
-    <xref linkend="guc-archive-mode"> configuration variable)
+    WAL archiving or streaming replication, you might want to disable
+    archiving (turn off the <xref linkend="guc-archive-mode">
+    configuration variable) and replication (zero the
+    <xref linkend="guc-max-wal-senders"> configuration variable)
     while loading.  It might be
     faster to take a new base backup after the load has completed
     than to process a large amount of incremental WAL data.
-    But note that turning <varname>archive_mode</varname> on or off
-    requires a server restart.
+    But note that changing either of these variables requires
+    a server restart.
    </para>
 
    <para>
-    Aside from avoiding the time for the archiver to process the WAL data,
+    Aside from avoiding the time for the archiver or WAL sender to
+    process the WAL data,
     doing this will actually make certain commands faster, because they
     are designed not to write WAL at all if <varname>archive_mode</varname>
-    is off.  (They can guarantee crash safety more cheaply by doing an
+    is off and <varname>max_wal_senders</varname> is zero.  (They can
+    guarantee crash safety more cheaply by doing an
     <function>fsync</> at the end than by writing WAL.)
     This applies to the following commands:
     <itemizedlist>
