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"> <chapter id="backup">
<title>Backup and Restore</title> <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>
<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 are optimized to avoid WAL logging, as described in <xref
linkend="populate-pitr">. If archiving were turned on during execution linkend="populate-pitr">. If archiving or streaming replication were
of one of these statements, WAL would not contain enough information turned on during execution of one of these statements, WAL would not
for archive recovery. (Crash recovery is unaffected.) For contain enough information for archive recovery. (Crash recovery is
this reason, <varname>archive_mode</> can only be changed at server unaffected.) For this reason, these parameters can only be changed at
start. However, <varname>archive_command</> can be changed with a server start. However, <varname>archive_command</> can be changed with a
configuration file reload. If you wish to temporarily stop archiving, configuration file reload. If you wish to temporarily stop archiving,
one way to do it is to set <varname>archive_command</> to the empty one way to do it is to set <varname>archive_command</> to the empty
string (<literal>''</>). 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"> <chapter id="performance-tips">
<title>Performance Tips</title> <title>Performance Tips</title>
@ -910,24 +910,28 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse;
</sect2> </sect2>
<sect2 id="populate-pitr"> <sect2 id="populate-pitr">
<title>Turn off <varname>archive_mode</varname></title> <title>Turn off <varname>archive_mode</varname> and streaming replication</title>
<para> <para>
When loading large amounts of data into an installation that uses When loading large amounts of data into an installation that uses
WAL archiving, you might want to disable archiving (turn off the WAL archiving or streaming replication, you might want to disable
<xref linkend="guc-archive-mode"> configuration variable) 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 while loading. It might be
faster to take a new base backup after the load has completed faster to take a new base backup after the load has completed
than to process a large amount of incremental WAL data. than to process a large amount of incremental WAL data.
But note that turning <varname>archive_mode</varname> on or off But note that changing either of these variables requires
requires a server restart. a server restart.
</para> </para>
<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 doing this will actually make certain commands faster, because they
are designed not to write WAL at all if <varname>archive_mode</varname> 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.) <function>fsync</> at the end than by writing WAL.)
This applies to the following commands: This applies to the following commands:
<itemizedlist> <itemizedlist>