mirror/postgresql
2
0
Fork 0
mirror of https://git.postgresql.org/git/postgresql.git synced 2024-12-27 08:39:28 +08:00
Code Issues Packages Projects Releases Wiki Activity

Update docs as to when WAL logging can be skipped.

Browse Source 
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
This commit is contained in:
Robert Haas 2010-04-20 00:26:06 +00:00
parent cfac702223
commit ee7769bb76
2 changed files with 20 additions and 15 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
doc/src/sgml/backup.sgml
View File

@ -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>''</>).

20
doc/src/sgml/perform.sgml
View File

@ -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>