they happened on the publisher.  Once synchronization is done,
     control of the replication of the table is given back to the main apply
     process where replication continues as normal.
    </para>
    <note>
     <para>
      The publication
      <link linkend="sql-createpublication-params-with-publish"><literal>publish</literal></link>
      parameter only affects what DML operations will be replicated. The
      initial data synchronization does not take this parameter into account
      when copying the existing table data.
     </para>
    </note>
    <note>
     <para>
      If a table synchronization worker fails during copy, the apply worker
      detects the failure and respawns the table synchronization worker to
      continue the synchronization process. This behaviour ensures that
      transient errors do not permanently disrupt the replication setup. See
      also <link linkend="guc-wal-retrieve-retry-interval"><varname>wal_retrieve_retry_interval</varname></link>.
     </para>
    </note>
  </sect2>
 </sect1>

 <sect1 id="logical-replication-monitoring">
  <title>Monitoring</title>

  <para>
   Because logical replication is based on a similar architecture as
   <link linkend="streaming-replication">physical streaming replication</link>,
   the monitoring on a publication node is similar to monitoring of a
   physical replication primary
   (see <xref linkend="streaming-replication-monitoring"/>).
  </para>

  <para>
   The monitoring information about subscription is visible in
   <link linkend="monitoring-pg-stat-subscription">
   <structname>pg_stat_subscription</structname></link>.
   This view contains one row for every subscription worker.  A subscription
   can have zero or more active subscription workers depending on its state.
  </para>

  <para>
   Normally, there is a single apply process running for an enabled
   subscription.  A disabled subscription or a crashed subscription will have
   zero rows in this view.  If the initial data synchronization of any
   table is in progress, there will be additional workers for the tables
   being synchronized. Moreover, if the
   <link linkend="sql-createsubscription-params-with-streaming"><literal>streaming</literal></link>
   transaction is applied in parallel, there may be additional parallel apply
   workers.
  </para>
 </sect1>

 <sect1 id="logical-replication-security">
  <title>Security</title>

  <para>
   The role used for the replication connection must have
   the <literal>REPLICATION</literal> attribute (or be a superuser).  If the
   role lacks <literal>SUPERUSER</literal> and <literal>BYPASSRLS</literal>,
   publisher row security policies can execute.  If the role does not trust
   all table owners, include <literal>options=-crow_security=off</literal> in
   the connection string; if a table owner then adds a row security policy,
   that setting will cause replication to halt rather than execute the policy.
   Access for the role must be configured in <filename>pg_hba.conf</filename>
   and it must have the <literal>LOGIN</literal> attribute.
  </para>

  <para>
   In order to be able to copy the initial table data, the role used for the
   replication connection must have the <literal>SELECT</literal> privilege on
   a published table (or be a superuser).
  </para>

  <para>
   To create a publication, the user must have the <literal>CREATE</literal>
   privilege in the database.
  </para>

  <para>
   To add tables to a publication, the user must have ownership rights on the
   table. To add all tables in schema to a publication, the user must be a
   superuser. To create a publication that publishes all tables or all tables in
   schema automatically, the user must be a superuser.
  </para>

  <para>
   There are currently no privileges on publications.  Any subscription (that
   is able to connect) can access any publication.  Thus, if you intend to
   hide some information from particular subscribers, such as by using row
   filters