linkend="synchronous-replication"/>).  The standby
   name is by default the subscription name.  An alternative name can be
   specified as <literal>application_name</literal> in the connection
   information of the subscription.
  </para>

  <para>
   Subscriptions are dumped by <command>pg_dump</command> if the current user
   is a superuser.  Otherwise a warning is written and subscriptions are
   skipped, because non-superusers cannot read all subscription information
   from the <structname>pg_subscription</structname> catalog.
  </para>

  <para>
   The subscription is added using <link linkend="sql-createsubscription"><command>CREATE SUBSCRIPTION</command></link> and
   can be stopped/resumed at any time using the
   <link linkend="sql-altersubscription"><command>ALTER SUBSCRIPTION</command></link> command and removed using
   <link linkend="sql-dropsubscription"><command>DROP SUBSCRIPTION</command></link>.
  </para>

  <para>
   When a subscription is dropped and recreated, the synchronization
   information is lost.  This means that the data has to be resynchronized
   afterwards.
  </para>

  <para>
   The schema definitions are not replicated, and the published tables must
   exist on the subscriber.  Only regular tables may be
   the target of replication.  For example, you can't replicate to a view.
  </para>

  <para>
   The tables are matched between the publisher and the subscriber using the
   fully qualified table name.  Replication to differently-named tables on the
   subscriber is not supported.
  </para>

  <para>
   Columns of a table are also matched by name.  The order of columns in the
   subscriber table does not need to match that of the publisher.  The data
   types of the columns do not need to match, as long as the text
   representation of the data can be converted to the target type.  For
   example, you can replicate from a column of type <type>integer</type> to a
   column of type <type>bigint</type>.  The target table can also have
   additional columns not provided by the published table.  Any such columns
   will be filled with the default value as specified in the definition of the
   target table. However, logical replication in binary format is more
   restrictive. See the
   <link linkend="sql-createsubscription-params-with-binary"><literal>binary</literal></link>
   option of <command>CREATE SUBSCRIPTION</command> for details.
  </para>

  <sect2 id="logical-replication-subscription-slot">
   <title>Replication Slot Management</title>

   <para>
    As mentioned earlier, each (active) subscription receives changes from a
    replication slot on the remote (publishing) side.
   </para>
   <para>
    Additional table synchronization slots are normally transient, created
    internally to perform initial table synchronization and dropped
    automatically when they are no longer needed. These table synchronization
    slots have generated names: <quote><literal>pg_%u_sync_%u_%llu</literal></quote>
    (parameters: Subscription <parameter>oid</parameter>,
    Table <parameter>relid</parameter>, system identifier <parameter>sysid</parameter>)
   </para>
   <para>
    Normally, the remote replication slot is created automatically when the
    subscription is created using <link linkend="sql-createsubscription">
    <command>CREATE SUBSCRIPTION</command></link> and it
    is dropped automatically when the subscription is dropped using
    <link linkend="sql-dropsubscription"><command>DROP SUBSCRIPTION</command></link>.
    In some situations, however, it can
    be useful or necessary to manipulate the subscription and the underlying
    replication slot separately.  Here are some scenarios:

    <itemizedlist>
     <listitem>
      <para>
       When creating a subscription, the replication slot already exists.  In
       that case, the subscription can be created using
       the <literal>create_slot = false</literal> option to associate with the
       existing slot.
      </para>
     </listitem>