(use
          <literal>replication</literal> as the database name).
         </para>
         <para>
          For replication slot synchronization (see
          <xref linkend="logicaldecoding-replication-slots-synchronization"/>),
          it is also necessary to specify a valid <literal>dbname</literal>
          in the <varname>primary_conninfo</varname> string. This will only be
          used for slot synchronization. It is ignored for streaming.
         </para>
         <para>
          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 (except if <varname>primary_conninfo</varname>
          is an empty string).
          This setting has no effect if the server is not in standby mode.
         </para>
        </listitem>
       </varlistentry>
       <varlistentry id="guc-primary-slot-name" xreflabel="primary_slot_name">
        <term><varname>primary_slot_name</varname> (<type>string</type>)
        <indexterm>
          <primary><varname>primary_slot_name</varname> configuration parameter</primary>
        </indexterm>
        </term>
        <listitem>
         <para>
          Optionally specifies an existing replication slot to be used when
          connecting to the sending server via streaming replication to control
          resource removal on the upstream node
          (see <xref linkend="streaming-replication-slots"/>).
          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.
          This setting has no effect if <varname>primary_conninfo</varname> is not
          set or the server is not in standby mode.
         </para>
        </listitem>
       </varlistentry>

     <varlistentry id="guc-hot-standby" xreflabel="hot_standby">
      <term><varname>hot_standby</varname> (<type>boolean</type>)
      <indexterm>
       <primary><varname>hot_standby</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        Specifies whether or not you can connect and run queries during
        recovery, as described in <xref linkend="hot-standby"/>.
        The default value is <literal>on</literal>.
        This parameter can only be set at server start. It only has effect
        during archive recovery or in standby mode.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-max-standby-archive-delay" xreflabel="max_standby_archive_delay">
      <term><varname>max_standby_archive_delay</varname> (<type>integer</type>)
      <indexterm>
       <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