Home Explore Blog CI



postgresql

9th chunk of `doc/src/sgml/ref/pg_createsubscriber.sgml`
7cdb580c765ab823dc2af54ecce18439fc377066fff64e830000000100000c7f
 </para>
    </step>

    <step>
     <para>
      Create a subscription for each specified database on the target server.
      If the <option>--subscription</option> option is not specified, the
      subscription has the following name pattern:
      <quote><literal>pg_createsubscriber_%u_%x</literal></quote> (parameters:
      database <parameter>oid</parameter>, random <parameter>int</parameter>).
      It does not copy existing data from the source server.  It does not
      create a replication slot.  Instead, it uses the replication slot that
      was created in a previous step.  The subscription is created but it is
      not enabled yet.  The reason is the replication progress must be set to
      the replication start point before starting the replication.
     </para>
    </step>

    <step>
     <para>
      Drop publications on the target server that were replicated because they
      were created before the replication start location.  It has no use on
      the subscriber.
     </para>
    </step>

    <step>
     <para>
      Set the replication progress to the replication start point for each
      subscription.  When the target server starts the recovery process, it
      catches up to the replication start point.  This is the exact LSN to be
      used as a initial replication location for each subscription.  The
      replication origin name is obtained since the subscription was created.
      The replication origin name and the replication start point are used in
      <link
      linkend="pg-replication-origin-advance"><function>pg_replication_origin_advance()</function></link>
      to set up the initial replication location.
     </para>
    </step>

    <step>
     <para>
      Enable the subscription for each specified database on the target server.
      The subscription starts applying transactions from the replication start
      point.
     </para>
    </step>

    <step>
     <para>
      If the standby server was using <xref linkend="guc-primary-slot-name"/>,
      it has no use from now on so drop it.
     </para>
    </step>

    <step>
     <para>
      If the standby server contains <link
      linkend="logicaldecoding-replication-slots-synchronization">failover
      replication slots</link>, they cannot be synchronized anymore, so drop
      them.
     </para>
    </step>

    <step>
     <para>
      Update the system identifier on the target server. The
      <xref linkend="app-pgresetwal"/> is run to modify the system identifier.
      The target server is stopped as a <command>pg_resetwal</command> requirement.
     </para>
    </step>
   </procedure>
  </refsect2>
 </refsect1>

 <refsect1>
  <title>Examples</title>

  <para>
   To create a logical replica for databases <literal>hr</literal> and
   <literal>finance</literal> from a physical replica at
   <literal>foo</literal>:
<screen>
<prompt>$</prompt> <userinput>pg_createsubscriber -D /usr/local/pgsql/data -P "host=foo" -d hr -d finance</userinput>
</screen>
  </para>
 </refsect1>

 <refsect1>
  <title>See Also</title>

  <simplelist type="inline">
   <member><xref linkend="app-pgbasebackup"/></member>
  </simplelist>
 </refsect1>
</refentry>

Title: pg_createsubscriber Steps 8-13 and Examples
Summary
This section details the remaining steps of `pg_createsubscriber`, including setting the replication progress to the replication start point for each subscription and enabling the subscription. The function also handles the clean up of the standby server by dropping the primary slot name if used and dropping any failover replication slots. Finally, the system identifier on the target server is updated by using `pg_resetwal`. The end of this section provides an example command for creating a logical replica for databases `hr` and `finance`.