*** a/doc/src/sgml/backup.sgml
--- b/doc/src/sgml/backup.sgml
***************
*** 688,696 **** archive_command = 'test ! -f .../%f && cp %p .../%f'
     </para>
  
     <para>
!     When <varname>archive_mode</> is <literal>off</> 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
--- 688,698 ----
     </para>
  
     <para>
!     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">. When streaming replication is disabled,
!     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
*** a/doc/src/sgml/perform.sgml
--- b/doc/src/sgml/perform.sgml
***************
*** 910,933 **** SELECT * FROM x, y, a, b, c WHERE something AND somethingelse;
    </sect2>
  
    <sect2 id="populate-pitr">
!    <title>Turn off <varname>archive_mode</varname></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)
      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.
     </para>
  
     <para>
!     Aside from avoiding the time for the archiver 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
      <function>fsync</> at the end than by writing WAL.)
      This applies to the following commands:
      <itemizedlist>
--- 910,938 ----
    </sect2>
  
    <sect2 id="populate-pitr">
!    <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 or streaming replication, you might want to disable
!     archiving (turn off the <xref linkend="guc-archive-mode">
!     configuration variable) or 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,
!     and changing <varname>max_wal_senders</varname> require
!     a server restart.
     </para>
  
     <para>
!     Aside from avoiding the time for the archiver or the 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 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>