<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>