<primary><varname>max_standby_archive_delay</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        When hot standby is active, this parameter determines how long the
        standby server should wait before canceling standby queries that
        conflict with about-to-be-applied WAL entries, as described in
        <xref linkend="hot-standby-conflict"/>.
        <varname>max_standby_archive_delay</varname> applies when WAL data is
        being read from WAL archive (and is therefore not current).
        If this value is specified without units, it is taken as milliseconds.
        The default is 30 seconds.
        A value of -1 allows the standby to wait forever for conflicting
        queries to complete.
        This parameter can only be set in the <filename>postgresql.conf</filename>
        file or on the server command line.
       </para>
       <para>
        Note that <varname>max_standby_archive_delay</varname> is not the same as the
        maximum length of time a query can run before cancellation; rather it
        is the maximum total time allowed to apply any one WAL segment's data.
        Thus, if one query has resulted in significant delay earlier in the
        WAL segment, subsequent conflicting queries will have much less grace
        time.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-max-standby-streaming-delay" xreflabel="max_standby_streaming_delay">
      <term><varname>max_standby_streaming_delay</varname> (<type>integer</type>)
      <indexterm>
       <primary><varname>max_standby_streaming_delay</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        When hot standby is active, this parameter determines how long the
        standby server should wait before canceling standby queries that
        conflict with about-to-be-applied WAL entries, as described in
        <xref linkend="hot-standby-conflict"/>.
        <varname>max_standby_streaming_delay</varname> applies when WAL data is
        being received via streaming replication.
        If this value is specified without units, it is taken as milliseconds.
        The default is 30 seconds.
        A value of -1 allows the standby to wait forever for conflicting
        queries to complete.
        This parameter can only be set in the <filename>postgresql.conf</filename>
        file or on the server command line.
       </para>
       <para>
        Note that <varname>max_standby_streaming_delay</varname> is not the same as
        the maximum length of time a query can run before cancellation; rather
        it is the maximum total time allowed to apply WAL data once it has
        been received from the primary server.  Thus, if one query has
        resulted in significant delay, subsequent conflicting queries will
        have much less grace time until the standby server has caught up
        again.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-wal-receiver-create-temp-slot" xreflabel="wal_receiver_create_temp_slot">
      <term><varname>wal_receiver_create_temp_slot</varname> (<type>boolean</type>)
      <indexterm>
       <primary><varname>wal_receiver_create_temp_slot</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        Specifies whether the WAL receiver process should create a temporary replication
        slot on the remote instance when no permanent replication slot to use
        has been configured (using <xref linkend="guc-primary-slot-name"/>).
        The default is off.  This parameter can only be set in the
        <filename>postgresql.conf</filename> file or on the server command line.
        If this parameter is changed while the WAL receiver process is running,
        that process is signaled to shut down and expected to restart with
        the new setting.