<listitem>
       <para>
        Do not error out when <option>--create-slot</option> is specified
        and a slot with the specified name already exists.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><option>-n</option></term>
      <term><option>--no-loop</option></term>
      <listitem>
       <para>
        Don't loop on connection errors. Instead, exit right away with
        an error.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><option>--no-sync</option></term>
      <listitem>
       <para>
        This option causes <command>pg_receivewal</command> to not force WAL
        data to be flushed to disk.  This is faster, but means that a
        subsequent operating system crash can leave the WAL segments corrupt.
        Generally, this option is useful for testing but should not be used
        when doing WAL archiving on a production deployment.
       </para>

       <para>
        This option is incompatible with <literal>--synchronous</literal>.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><option>-s <replaceable class="parameter">interval</replaceable></option></term>
      <term><option>--status-interval=<replaceable class="parameter">interval</replaceable></option></term>
      <listitem>
       <para>
        Specifies the number of seconds between status packets sent back to the
        server. This allows for easier monitoring of the progress from server.
        A value of zero disables the periodic status updates completely,
        although an update will still be sent when requested by the server, to
        avoid timeout disconnect. The default value is 10 seconds.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><option>-S <replaceable>slotname</replaceable></option></term>
      <term><option>--slot=<replaceable class="parameter">slotname</replaceable></option></term>
      <listitem>
        <para>
         Require <application>pg_receivewal</application> to use an existing
         replication slot (see <xref linkend="streaming-replication-slots"/>).
         When this option is used, <application>pg_receivewal</application> will report
         a flush position to the server, indicating when each segment has been
         synchronized to disk so that the server can remove that segment if it
         is not otherwise needed.
        </para>

        <para>
         When the replication client
         of <application>pg_receivewal</application> is configured on the
         server as a synchronous standby, then using a replication slot will
         report the flush position to the server, but only when a WAL file is
         closed.  Therefore, that configuration will cause transactions on the
         primary to wait for a long time and effectively not work
         satisfactorily.  The option <literal>--synchronous</literal> (see
         below) must be specified in addition to make this work correctly.
        </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><option>--synchronous</option></term>
      <listitem>
       <para>
        Flush the WAL data to disk immediately after it has been received. Also
        send a status packet back to the server immediately after flushing,
        regardless of <literal>--status-interval</literal>.
       </para>

       <para>
        This option should be specified if the replication client
        of <application>pg_receivewal</application> is configured on the
        server as a synchronous standby, to ensure that timely feedback is
        sent to the server.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term><option>-v</option></term>
      <term><option>--verbose</option></term>
      <listitem>
       <para>
        Enables verbose mode.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>