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>

     <listitem>
      <para>
       When creating a subscription, the remote host is not reachable or in an
       unclear state.  In that case, the subscription can be created using
       the <literal>connect = false</literal> option.  The remote host will then not
       be contacted at all.  This is what <application>pg_dump</application>
       uses.  The remote replication slot will then have to be created
       manually before the subscription can be activated.
      </para>
     </listitem>

     <listitem>
      <para>
       When dropping a subscription, the replication slot should be kept.
       This could be useful when the subscriber database is being moved to a
       different host and will be activated from there.  In that case,
       disassociate the slot from the subscription using
       <link linkend="sql-altersubscription"><command>ALTER SUBSCRIPTION</command></link>
       before attempting to drop the subscription.
      </para>
     </listitem>

     <listitem>
      <para>
       When dropping a subscription, the remote host is not reachable.  In
       that case, disassociate the slot from the subscription
       using <command>ALTER SUBSCRIPTION</command> before attempting to drop
       the subscription.  If the remote database instance no longer exists, no
       further action is then necessary.  If, however, the remote database
       instance is just unreachable, the replication slot (and any still
       remaining table synchronization slots) should then be
       dropped manually; otherwise it/they would continue to reserve WAL and might
       eventually cause the disk to fill up.  Such cases should be carefully
       investigated.
      </para>
     </listitem>
    </itemizedlist>
   </para>
  </sect2>

  <sect2 id="logical-replication-subscription-examples">
    <title>Examples: Set Up Logical Replication</title>

    <para>
     Create some test tables on the publisher.
<programlisting>
/* pub # */ CREATE TABLE t1(a int, b text, PRIMARY KEY(a));
/* pub # */ CREATE TABLE t2(c int, d text, PRIMARY KEY(c));
/* pub # */ CREATE TABLE t3(e int, f text, PRIMARY KEY(e));
</programlisting></para>

    <para>
     Create the same tables on the subscriber.
<programlisting>
/* sub # */ CREATE TABLE t1(a int, b text, PRIMARY KEY(a));
/* sub # */ CREATE TABLE t2(c int, d text, PRIMARY KEY(c));
/* sub # */ CREATE TABLE t3(e int, f text, PRIMARY KEY(e));
</programlisting></para>

    <para>
     Insert data to the tables at the publisher side.
<programlisting>
/* pub # */ INSERT INTO t1 VALUES (1, 'one'), (2, 'two'), (3, 'three');
/* pub # */ INSERT INTO t2 VALUES (1, 'A'), (2, 'B'), (3, 'C');
/* pub # */ INSERT INTO t3 VALUES (1, 'i'), (2, 'ii'), (3, 'iii');
</programlisting></para>

    <para>
     Create publications for the tables. The publications <literal>pub2</literal>
     and <literal>pub3a</literal> disallow some
     <link linkend="sql-createpublication-params-with-publish"><literal>publish</literal></link>