the
        option <option>-C</option> is also used.
       </para>
       <para>
        If this option is not specified and the server supports temporary
        replication slots (version 10 and later), then a temporary replication
        slot is automatically used for WAL streaming.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><option>--sync-method=<replaceable class="parameter">method</replaceable></option></term>
      <listitem>
       <para>
        When set to <literal>fsync</literal>, which is the default,
        <command>pg_basebackup</command> will recursively open and synchronize
        all files in the backup directory.  When the plain format is used, the
        search for files will follow symbolic links for the WAL directory and
        each configured tablespace.
       </para>
       <para>
        On Linux, <literal>syncfs</literal> may be used instead to ask the
        operating system to synchronize the whole file system that contains the
        backup directory.  When the plain format is used,
        <command>pg_basebackup</command> will also synchronize the file systems
        that contain the WAL files and each tablespace.  See
        <xref linkend="guc-recovery-init-sync-method"/> for information about
        the caveats to be aware of when using <literal>syncfs</literal>.
       </para>
       <para>
        This option has no effect when <option>--no-sync</option> is used.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><option>-v</option></term>
      <term><option>--verbose</option></term>
      <listitem>
       <para>
        Enables verbose mode. Will output some extra steps during startup and
        shutdown, as well as show the exact file name that is currently being
        processed if progress reporting is also enabled.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><option>--manifest-checksums=<replaceable class="parameter">algorithm</replaceable></option></term>
      <listitem>
       <para>
        Specifies the checksum algorithm that should be applied to each file
        included in the backup manifest. Currently, the available
        algorithms are <literal>NONE</literal>, <literal>CRC32C</literal>,
        <literal>SHA224</literal>, <literal>SHA256</literal>,
        <literal>SHA384</literal>, and <literal>SHA512</literal>.
        The default is <literal>CRC32C</literal>.
       </para>
       <para>
        If <literal>NONE</literal> is selected, the backup manifest will
        not contain any checksums. Otherwise, it will contain a checksum
        of each file in the backup using the specified algorithm. In addition,
        the manifest will always contain a <literal>SHA256</literal>
        checksum of its own contents. The <literal>SHA</literal> algorithms
        are significantly more CPU-intensive than <literal>CRC32C</literal>,
        so selecting one of them may increase the time required to complete
        the backup.
       </para>
       <para>
        Using a SHA hash function provides a cryptographically secure digest
        of each file for users who wish to verify that the backup has not been
        tampered with, while the CRC-32C algorithm provides a checksum that is
        much faster to calculate; it is good at catching errors due to accidental
        changes but is not resistant to malicious modifications.  Note that, to
        be useful against an adversary who has access to the backup, the backup
        manifest would need to be stored securely elsewhere or otherwise
        verified not to have been modified since the backup was taken.
       </para>
       <para>
        <xref linkend="app-pgverifybackup"/> can be used to check the
        integrity of a backup against the backup manifest.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><option>--manifest-force-encode</option></term>