<primary><varname>hot_standby_feedback</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        Specifies whether or not a hot standby will send feedback to the primary
        or upstream standby
        about queries currently executing on the standby. This parameter can
        be used to eliminate query cancels caused by cleanup records, but
        can cause database bloat on the primary for some workloads.
        Feedback messages will not be sent more frequently than once per
        <varname>wal_receiver_status_interval</varname>. The default value is
        <literal>off</literal>. This parameter can only be set in the
        <filename>postgresql.conf</filename> file or on the server command line.
       </para>
       <para>
        If cascaded replication is in use the feedback is passed upstream
        until it eventually reaches the primary.  Standbys make no other use
        of feedback they receive other than to pass upstream.
       </para>
       <para>
        Note that if the clock on standby is moved ahead or backward, the
        feedback message might not be sent at the required interval.  In
        extreme cases, this can lead to a prolonged risk of not removing dead
        rows on the primary for extended periods, as the feedback mechanism is
        based on timestamps.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-wal-receiver-timeout" xreflabel="wal_receiver_timeout">
      <term><varname>wal_receiver_timeout</varname> (<type>integer</type>)
      <indexterm>
       <primary><varname>wal_receiver_timeout</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        Terminate replication connections that are inactive for longer
        than this amount of time. This is useful for
        the receiving standby server to detect a primary node crash or network
        outage.
        If this value is specified without units, it is taken as milliseconds.
        The default value is 60 seconds.
        A value of zero disables the timeout mechanism.
        This parameter can only be set in
        the <filename>postgresql.conf</filename> file or on the server
        command line.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-wal-retrieve-retry-interval" xreflabel="wal_retrieve_retry_interval">
      <term><varname>wal_retrieve_retry_interval</varname> (<type>integer</type>)
      <indexterm>
       <primary><varname>wal_retrieve_retry_interval</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        Specifies how long the standby server should wait when WAL data is not
        available from any sources (streaming replication,
        local <filename>pg_wal</filename> or WAL archive) before trying
        again to retrieve WAL data.
        If this value is specified without units, it is taken as milliseconds.
        The default value is 5 seconds.
        This parameter can only be set in
        the <filename>postgresql.conf</filename> file or on the server
        command line.
       </para>
       <para>
        This parameter is useful in configurations where a node in recovery
        needs to control the amount of time to wait for new WAL data to be
        available. For example, in archive recovery, it is possible to
        make the recovery more responsive in the detection of a new WAL
        file by reducing the value of this parameter. On a system with
        low WAL activity, increasing it reduces the amount of requests necessary
        to access WAL archives, something useful for example in cloud
        environments where the number of times an infrastructure is accessed
        is taken into account.
       </para>
       <para>
        In logical replication, this parameter also limits how often a failing
        replication apply worker