<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 or column lists, or by not adding the whole table to the
   publication, be aware that other publications in the same database could
   expose the same information.  Publication privileges might be added to
   <productname>PostgreSQL</productname> in the future to allow for
   finer-grained access control.
  </para>

  <para>
   To create a subscription, the user must have the privileges of
   the <literal>pg_create_subscription</literal> role, as well as
   <literal>CREATE</literal> privileges on the database.
  </para>

  <para>
   The subscription apply process will, at a session level, run with the
   privileges of the subscription owner. However, when performing an insert,
   update, delete, or truncate operation on a particular table, it will switch
   roles to the table owner and perform the operation with the table owner's
   privileges. This means that the subscription owner needs to be able to
   <literal>SET ROLE</literal> to each role that owns a replicated table.
  </para>

  <para>
   If the subscription has been configured with
   <literal>run_as_owner = true</literal>, then no user switching will
   occur. Instead, all operations will be performed with the permissions
   of the subscription owner. In this case, the subscription owner only
   needs privileges to <literal>SELECT</literal>, <literal>INSERT</literal>,
   <literal>UPDATE</literal>, and <literal>DELETE</literal> from the
   target table, and does not need privileges to <literal>SET ROLE</literal>
   to the table owner. However, this also means that any user who owns
   a table into which replication is happening can execute arbitrary code with
   the privileges of the subscription owner. For example, they could do this
   by simply attaching a trigger to one of the tables which they own.
   Because it is usually undesirable to allow one role to freely assume
   the privileges of another, this option should be avoided unless user
   security within the database is of no concern.
  </para>

  <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>.