From ee7769bb7649e0f990179f9ed56e60c031542077 Mon Sep 17 00:00:00 2001
From: Robert Haas <rhaas@postgresql.org>
Date: Tue, 20 Apr 2010 00:26:06 +0000
Subject: [PATCH] Update docs as to when WAL logging can be skipped.
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
---
doc/src/sgml/backup.sgml | 15 ++++++++-------
doc/src/sgml/perform.sgml | 20 ++++++++++++--------
2 files changed, 20 insertions(+), 15 deletions(-)
diff --git a/doc/src/sgml/backup.sgml b/doc/src/sgml/backup.sgml
index 9dbcb4daa69..3c5e0d5a8ec 100644
--- 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 && 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
index d7c36cc4e9f..ccccb3fefb0 100644
--- 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>
--
GitLab