It is neither
     necessary nor desirable to stop normal operation of the database
     while you do this. See
     <xref linkend="backup-lowlevel-base-backup-data"/> for things to
     consider during this backup.
    </para>
   </listitem>
   <listitem>
    <para>
     In the same connection as before, issue the command:
<programlisting>
SELECT * FROM pg_backup_stop(wait_for_archive => true);
</programlisting>
     This terminates backup mode. On a primary, it also performs an automatic
     switch to the next WAL segment.  On a standby, it is not possible to
     automatically switch WAL segments, so you may wish to run
     <function>pg_switch_wal</function> on the primary to perform a manual
     switch. The reason for the switch is to arrange for
     the last WAL segment file written during the backup interval to be
     ready to archive.
    </para>
    <para>
     <function>pg_backup_stop</function> will return one row with three
     values. The second of these fields should be written to a file named
     <filename>backup_label</filename> in the root directory of the backup. The
     third field should be written to a file named
     <filename>tablespace_map</filename> unless the field is empty. These files are
     vital to the backup working and must be written byte for byte without
     modification, which may require opening the file in binary mode.
    </para>
   </listitem>
   <listitem>
    <para>
     Once the WAL segment files active during the backup are archived, you are
     done.  The file identified by <function>pg_backup_stop</function>'s first return
     value is the last segment that is required to form a complete set of
     backup files.  On a primary, if <varname>archive_mode</varname> is enabled and the
     <literal>wait_for_archive</literal> parameter is <literal>true</literal>,
     <function>pg_backup_stop</function> does not return until the last segment has
     been archived.
     On a standby, <varname>archive_mode</varname> must be <literal>always</literal> in order
     for <function>pg_backup_stop</function> to wait.
     Archiving of these files happens automatically since you have
     already configured <varname>archive_command</varname> or <varname>archive_library</varname>.
     In most cases this happens quickly, but you are advised to monitor your
     archive system to ensure there are no delays.
     If the archive process has fallen behind because of failures of the
     archive command or library, it will keep retrying
     until the archive succeeds and the backup is complete.
     If you wish to place a time limit on the execution of
     <function>pg_backup_stop</function>, set an appropriate
     <varname>statement_timeout</varname> value, but make note that if
     <function>pg_backup_stop</function> terminates because of this your backup
     may not be valid.
    </para>
    <para>
     If the backup process monitors and ensures that all WAL segment files
     required for the backup are successfully archived then the
     <literal>wait_for_archive</literal> parameter (which defaults to true) can be set
     to false to have
     <function>pg_backup_stop</function> return as soon as the stop backup record is
     written to the WAL.  By default, <function>pg_backup_stop</function> will wait
     until all WAL has been archived, which can take some time.  This option
     must be used with caution: if WAL archiving is not monitored correctly
     then the backup might not include all of the WAL files and will
     therefore be incomplete and not able to be restored.
    </para>
   </listitem>
  </orderedlist>
    </para>
   <sect3 id="backup-lowlevel-base-backup-data">
   <title>Backing Up the Data Directory</title>
   <para>
    Some file system backup tools emit warnings or errors
    if the files they are trying to copy change while the copy proceeds.
    When taking a base backup of an active database, this situation is normal
    and not an error.  However, you