file present in the backup with the exception of any WAL files that
           may be included. It also stores the size, last modification time, and
           optionally a checksum for each file.
           A value of <literal>force-encode</literal> forces all filenames
           to be hex-encoded; otherwise, this type of encoding is performed only
           for files whose names are non-UTF8 octet sequences.
           <literal>force-encode</literal> is intended primarily for testing
           purposes, to be sure that clients which read the backup manifest
           can handle this case. For compatibility with previous releases,
           the default is <literal>MANIFEST 'no'</literal>.
          </para>
         </listitem>
        </varlistentry>

        <varlistentry>
         <term><literal>MANIFEST_CHECKSUMS</literal> <replaceable>checksum_algorithm</replaceable></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>
         </listitem>
        </varlistentry>

        <varlistentry>
         <term><literal>INCREMENTAL</literal></term>
         <listitem>
          <para>
           Requests an incremental backup. The
           <literal>UPLOAD_MANIFEST</literal> command must be executed
           before running a base backup with this option.
          </para>
         </listitem>
        </varlistentry>
       </variablelist>
      </para>

      <para>
       When the backup is started, the server will first send two
       ordinary result sets, followed by one or more CopyOutResponse
       results.
      </para>

      <para>
       The first ordinary result set contains the starting position of the
       backup, in a single row with two columns. The first column contains
       the start position given in XLogRecPtr format, and the second column
       contains the corresponding timeline ID.
      </para>

      <para>
       The second ordinary result set has one row for each tablespace.
       The fields in this row are:

       <variablelist>
        <varlistentry>
         <term><literal>spcoid</literal> (<type>oid</type>)</term>
         <listitem>
          <para>
           The OID of the tablespace, or null if it's the base
           directory.
          </para>
         </listitem>
        </varlistentry>

        <varlistentry>
         <term><literal>spclocation</literal> (<type>text</type>)</term>
         <listitem>
          <para>
           The full path of the tablespace directory, or null
           if it's the base directory.
          </para>
         </listitem>
        </varlistentry>

        <varlistentry>
         <term><literal>size</literal> (<type>int8</type>)</term>
         <listitem>
          <para>
           The approximate size of the tablespace, in kilobytes (1024 bytes),
           if progress report has been requested; otherwise it's null.
          </para>
         </listitem>
        </varlistentry>
       </variablelist>
      </para>

      <para>
       After the second regular result set, a CopyOutResponse will be sent.
       The payload of each CopyData message will contain a message in one of
       the following formats:
      </para>

      <variablelist>
       <varlistentry>
        <term>new archive (B)</term>
        <listitem>
         <variablelist>
          <varlistentry>
           <term>Byte1('n')</term>
           <listitem><para>
            Identifies the message as indicating the start of a new archive.
            There will be one archive for the main data directory and one
            for each additional tablespace; each will