<para>
   On the publisher, privileges are only checked once at the start of a
   replication connection and are not re-checked as each change record is read.
  </para>

  <para>
   On the subscriber, the subscription owner's privileges are re-checked for
   each transaction when applied. If a worker is in the process of applying a
   transaction when the ownership of the subscription is changed by a
   concurrent transaction, the application of the current transaction will
   continue under the old owner's privileges.
  </para>
 </sect1>

 <sect1 id="logical-replication-config">
  <title>Configuration Settings</title>

  <para>
   Logical replication requires several configuration options to be set. These
   options are relevant only on one side of the replication.
  </para>

  <sect2 id="logical-replication-config-publisher">
   <title>Publishers</title>

   <para>
    <link linkend="guc-wal-level"><varname>wal_level</varname></link> must be
    set to <literal>logical</literal>.
   </para>

   <para>
    <link linkend="guc-max-replication-slots"><varname>max_replication_slots</varname></link>
    must be set to at least the number of subscriptions expected to connect,
    plus some reserve for table synchronization.
   </para>

   <para>
    Logical replication slots are also affected by
    <link linkend="guc-idle-replication-slot-timeout"><varname>idle_replication_slot_timeout</varname></link>.
   </para>

   <para>
    <link linkend="guc-max-wal-senders"><varname>max_wal_senders</varname></link>
    should be set to at least the same as
    <varname>max_replication_slots</varname>, plus the number of physical
    replicas that are connected at the same time.
   </para>

   <para>
    Logical replication walsender is also affected by
    <link linkend="guc-wal-sender-timeout"><varname>wal_sender_timeout</varname></link>.
   </para>

  </sect2>

  <sect2 id="logical-replication-config-subscriber">
   <title>Subscribers</title>

   <para>
    <link linkend="guc-max-active-replication-origins"><varname>max_active_replication_origins</varname></link>
    must be set to at least the number of subscriptions that will be added to
    the subscriber, plus some reserve for table synchronization.
   </para>

   <para>
    <link linkend="guc-max-logical-replication-workers"><varname>max_logical_replication_workers</varname></link>
    must be set to at least the number of subscriptions (for leader apply
    workers), plus some reserve for the table synchronization workers and
    parallel apply workers.
   </para>

   <para>
    <link linkend="guc-max-worker-processes"><varname>max_worker_processes</varname></link>
    may need to be adjusted to accommodate for replication workers, at least
    (<link linkend="guc-max-logical-replication-workers"><varname>max_logical_replication_workers</varname></link>
    + <literal>1</literal>). Note, some extensions and parallel queries also
    take worker slots from <varname>max_worker_processes</varname>.
   </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>