Skip to content

Commit ee7769b

Browse files
committed
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
1 parent cfac702 commit ee7769b

File tree

2 files changed

+20
-15
lines changed

2 files changed

+20
-15
lines changed

doc/src/sgml/backup.sgml

Lines changed: 8 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
<!-- $PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.151 2010/04/12 19:08:28 momjian Exp $ -->
1+
<!-- $PostgreSQL: pgsql/doc/src/sgml/backup.sgml,v 2.152 2010/04/20 00:26:06 rhaas Exp $ -->
22

33
<chapter id="backup">
44
<title>Backup and Restore</title>
@@ -689,13 +689,14 @@ archive_command = 'test ! -f /mnt/server/archivedir/%f &amp;&amp; cp %p /mnt/ser
689689
</para>
690690

691691
<para>
692-
When <varname>archive_mode</> is <literal>off</> some SQL commands
692+
When <varname>archive_mode</> is <literal>off</> and <xref
693+
linkend="guc-max-wal-senders"> is zero some SQL commands
693694
are optimized to avoid WAL logging, as described in <xref
694-
linkend="populate-pitr">. If archiving were turned on during execution
695-
of one of these statements, WAL would not contain enough information
696-
for archive recovery. (Crash recovery is unaffected.) For
697-
this reason, <varname>archive_mode</> can only be changed at server
698-
start. However, <varname>archive_command</> can be changed with a
695+
linkend="populate-pitr">. If archiving or streaming replication were
696+
turned on during execution of one of these statements, WAL would not
697+
contain enough information for archive recovery. (Crash recovery is
698+
unaffected.) For this reason, these parameters can only be changed at
699+
server start. However, <varname>archive_command</> can be changed with a
699700
configuration file reload. If you wish to temporarily stop archiving,
700701
one way to do it is to set <varname>archive_command</> to the empty
701702
string (<literal>''</>).

doc/src/sgml/perform.sgml

Lines changed: 12 additions & 8 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
<!-- $PostgreSQL: pgsql/doc/src/sgml/perform.sgml,v 1.75 2010/04/03 07:22:55 petere Exp $ -->
1+
<!-- $PostgreSQL: pgsql/doc/src/sgml/perform.sgml,v 1.76 2010/04/20 00:26:06 rhaas Exp $ -->
22

33
<chapter id="performance-tips">
44
<title>Performance Tips</title>
@@ -910,24 +910,28 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse;
910910
</sect2>
911911

912912
<sect2 id="populate-pitr">
913-
<title>Turn off <varname>archive_mode</varname></title>
913+
<title>Turn off <varname>archive_mode</varname> and streaming replication</title>
914914

915915
<para>
916916
When loading large amounts of data into an installation that uses
917-
WAL archiving, you might want to disable archiving (turn off the
918-
<xref linkend="guc-archive-mode"> configuration variable)
917+
WAL archiving or streaming replication, you might want to disable
918+
archiving (turn off the <xref linkend="guc-archive-mode">
919+
configuration variable) and replication (zero the
920+
<xref linkend="guc-max-wal-senders"> configuration variable)
919921
while loading. It might be
920922
faster to take a new base backup after the load has completed
921923
than to process a large amount of incremental WAL data.
922-
But note that turning <varname>archive_mode</varname> on or off
923-
requires a server restart.
924+
But note that changing either of these variables requires
925+
a server restart.
924926
</para>
925927

926928
<para>
927-
Aside from avoiding the time for the archiver to process the WAL data,
929+
Aside from avoiding the time for the archiver or WAL sender to
930+
process the WAL data,
928931
doing this will actually make certain commands faster, because they
929932
are designed not to write WAL at all if <varname>archive_mode</varname>
930-
is off. (They can guarantee crash safety more cheaply by doing an
933+
is off and <varname>max_wal_senders</varname> is zero. (They can
934+
guarantee crash safety more cheaply by doing an
931935
<function>fsync</> at the end than by writing WAL.)
932936
This applies to the following commands:
933937
<itemizedlist>

0 commit comments

Comments
 (0)