must accept connections from the target server.  The
    source server must not be in recovery. The source server must have <xref
    linkend="guc-wal-level"/> as <literal>logical</literal>.  The source server
    must have <xref linkend="guc-max-replication-slots"/> configured to a value
    greater than or equal to the number of specified databases plus existing
    replication slots.  The source server must have <xref
    linkend="guc-max-wal-senders"/> configured to a value greater than or equal
    to the number of specified databases and existing WAL sender processes.
   </para>
  </refsect2>

  <refsect2>
   <title>Warnings</title>

   <para>
    If <application>pg_createsubscriber</application> fails after the target
    server was promoted, then the data directory is likely not in a state that
    can be recovered.  In such case, creating a new standby server is
    recommended.
   </para>

   <para>
    <application>pg_createsubscriber</application> usually starts the target
    server with different connection settings during transformation.  Hence,
    connections to the target server should fail.
   </para>

   <para>
    Since DDL commands are not replicated by logical replication, avoid
    executing DDL commands that change the database schema while running
    <application>pg_createsubscriber</application>.  If the target server has
    already been converted to logical replica, the DDL commands might not be
    replicated, which might cause an error.
   </para>

   <para>
    If <application>pg_createsubscriber</application> fails while processing,
    objects (publications, replication slots) created on the source server are
    removed.  The removal might fail if the target server cannot connect to
    the source server.  In such a case, a warning message will inform the
    objects left.  If the target server is running, it will be stopped.
   </para>

   <para>
    If the replication is using <xref linkend="guc-primary-slot-name"/>, it
    will be removed from the source server after the logical replication
    setup.
   </para>

   <para>
    If the target server is a synchronous replica, transaction commits on the
    primary might wait for replication while running
    <application>pg_createsubscriber</application>.
   </para>

   <para>
    Unless the <option>--enable-two-phase</option> switch is specified,
    <application>pg_createsubscriber</application> sets up logical
    replication with two-phase commit disabled.  This means that any
    prepared transactions will be replicated at the time
    of <command>COMMIT PREPARED</command>, without advance preparation.
    Once setup is complete, you can manually drop and re-create the
    subscription(s) with
    the <link linkend="sql-createsubscription-params-with-two-phase"><literal>two_phase</literal></link>
    option enabled.
   </para>

   <para>
    <application>pg_createsubscriber</application> changes the system
    identifier using <application>pg_resetwal</application>.  It would avoid
    situations in which the target server might use WAL files from the source
    server.  If the target server has a standby, replication will break and a
    fresh standby should be created.
   </para>

   <para>
    Replication failures can occur if required WAL files are missing. To prevent
    this, the source server must set
    <xref linkend="guc-max-slot-wal-keep-size"/> to <literal>-1</literal> to
    ensure that required WAL files are not prematurely removed.
   </para>
  </refsect2>

  <refsect2>
   <title>How It Works</title>

   <para>
    The basic idea is to have a replication start point from the source server
    and set up a logical replication to start from this point:
   </para>

   <procedure>
    <step>
     <para>
      Start the target server with the specified command-line options.  If the
      target server is already running,
      <application>pg_createsubscriber</application> will terminate with an
      error.
     </para>
    </step>