</para>

   <para>
    <link linkend="guc-max-sync-workers-per-subscription"><varname>max_sync_workers_per_subscription</varname></link>
     controls the amount of parallelism of the initial data copy during the
     subscription initialization or when new tables are added.
   </para>

   <para>
    <link linkend="guc-max-parallel-apply-workers-per-subscription"><varname>max_parallel_apply_workers_per_subscription</varname></link>
     controls the amount of parallelism for streaming of in-progress
     transactions with subscription parameter
     <literal>streaming = parallel</literal>.
   </para>

   <para>
    Logical replication workers are also affected by
    <link linkend="guc-wal-receiver-timeout"><varname>wal_receiver_timeout</varname></link>,
    <link linkend="guc-wal-receiver-status-interval"><varname>wal_receiver_status_interval</varname></link> and
    <link linkend="guc-wal-retrieve-retry-interval"><varname>wal_retrieve_retry_interval</varname></link>.
   </para>

  </sect2>

 </sect1>

 <sect1 id="logical-replication-upgrade">
  <title>Upgrade</title>

  <para>
   Migration of <glossterm linkend="glossary-logical-replication-cluster">logical replication clusters</glossterm>
   is possible only when all the members of the old logical replication
   clusters are version 17.0 or later.
  </para>

  <sect2 id="prepare-publisher-upgrades">
   <title>Prepare for publisher upgrades</title>

   <para>
    <application>pg_upgrade</application> attempts to migrate logical
    slots. This helps avoid the need for manually defining the same
    logical slots on the new publisher. Migration of logical slots is
    only supported when the old cluster is version 17.0 or later.
    Logical slots on clusters before version 17.0 will silently be
    ignored.
   </para>

   <para>
    Before you start upgrading the publisher cluster, ensure that the
    subscription is temporarily disabled, by executing
    <link linkend="sql-altersubscription"><command>ALTER SUBSCRIPTION ... DISABLE</command></link>.
    Re-enable the subscription after the upgrade.
   </para>

   <para>
    There are some prerequisites for <application>pg_upgrade</application> to
    be able to upgrade the logical slots. If these are not met an error
    will be reported.
   </para>

   <itemizedlist>
    <listitem>
     <para>
      The new cluster must have
      <link linkend="guc-wal-level"><varname>wal_level</varname></link> as
      <literal>logical</literal>.
     </para>
    </listitem>
    <listitem>
     <para>
      The new cluster must have
      <link linkend="guc-max-replication-slots"><varname>max_replication_slots</varname></link>
      configured to a value greater than or equal to the number of slots
      present in the old cluster.
     </para>
    </listitem>
    <listitem>
     <para>
      The output plugins referenced by the slots on the old cluster must be
      installed in the new PostgreSQL executable directory.
     </para>
    </listitem>
    <listitem>
     <para>
      The old cluster has replicated all the transactions and logical decoding
      messages to subscribers.
     </para>
    </listitem>
    <listitem>
     <para>
      All slots on the old cluster must be usable, i.e., there are no slots
      whose
      <link linkend="view-pg-replication-slots">pg_replication_slots</link>.<structfield>conflicting</structfield>
      is not <literal>true</literal>.
     </para>
    </listitem>
    <listitem>
     <para>
      The new cluster must not have permanent logical slots, i.e.,
      there must be no slots where
      <link linkend="view-pg-replication-slots">pg_replication_slots</link>.<structfield>temporary</structfield>
      is <literal>false</literal>.
     </para>
    </listitem>
   </itemizedlist>
  </sect2>

  <sect2 id="prepare-subscriber-upgrades">
   <title>Prepare for subscriber upgrades</title>

   <para>
    Setup the <link linkend="logical-replication-config-subscriber">
    subscriber configurations</link>