slot_name |    lsn
-----------+-----------
 myslot    | 0/1905930
(1 row)
</programlisting></para>
     </listitem>
     <listitem>
      <para>
       On the subscriber, associate the subscription with the slot name just
       created.
<programlisting>
/* sub # */ ALTER SUBSCRIPTION sub1 SET (slot_name='myslot');
</programlisting></para>
     </listitem>
     <listitem>
      <para>
       The remaining subscription activation steps are same as before.
<programlisting>
/* sub # */ ALTER SUBSCRIPTION sub1 ENABLE;
/* sub # */ ALTER SUBSCRIPTION sub1 REFRESH PUBLICATION;
</programlisting></para>
     </listitem>
    </itemizedlist>
   </para>
  </sect2>

 </sect1>

 <sect1 id="logical-replication-failover">
  <title>Logical Replication Failover</title>

  <para>
   To allow subscriber nodes to continue replicating data from the publisher
   node even when the publisher node goes down, there must be a physical standby
   corresponding to the publisher node. The logical slots on the primary server
   corresponding to the subscriptions can be synchronized to the standby server by
   specifying <literal>failover = true</literal> when creating subscriptions. See
   <xref linkend="logicaldecoding-replication-slots-synchronization"/> for details.
   Enabling the
   <link linkend="sql-createsubscription-params-with-failover"><literal>failover</literal></link>
   parameter ensures a seamless transition of those subscriptions after the
   standby is promoted. They can continue subscribing to publications on the
   new primary server.
  </para>

  <para>
   Because the slot synchronization logic copies asynchronously, it is
   necessary to confirm that replication slots have been synced to the standby
   server before the failover happens. To ensure a successful failover, the
   standby server must be ahead of the subscriber. This can be achieved by
   configuring
   <link linkend="guc-synchronized-standby-slots"><varname>synchronized_standby_slots</varname></link>.
  </para>

  <para>
   To confirm that the standby server is indeed ready for failover, follow these
   steps to verify that all necessary logical replication slots have been
   synchronized to the standby server:
  </para>

  <procedure>
   <step performance="required">
    <para>
     On the subscriber node, use the following SQL to identify which replication
     slots should be synced to the standby that we plan to promote. This query
     will return the relevant replication slots associated with the
     failover-enabled subscriptions.
<programlisting>
/* sub # */ SELECT
               array_agg(quote_literal(s.subslotname)) AS slots
           FROM  pg_subscription s
           WHERE s.subfailover AND
                 s.subslotname IS NOT NULL;
 slots
-------
 {'sub1','sub2','sub3'}
(1 row)
</programlisting></para>
   </step>
   <step performance="required">
    <para>
     On the subscriber node, use the following SQL to identify which table
     synchronization slots should be synced to the standby that we plan to promote.
     This query needs to be run on each database that includes the failover-enabled
     subscription(s). Note that the table sync slot should be synced to the standby
     server only if the table copy is finished
     (See <xref linkend="catalog-pg-subscription-rel"/>).
     We don't need to ensure that the table sync slots are synced in other scenarios
     as they will either be dropped or re-created on the new primary server in those
     cases.
<programlisting>
/* sub # */ SELECT
               array_agg(quote_literal(slot_name)) AS slots
           FROM
           (
               SELECT CONCAT('pg_', srsubid, '_sync_', srrelid, '_', ctl.system_identifier) AS slot_name
               FROM pg_control_system() ctl, pg_subscription_rel r, pg_subscription s
               WHERE r.srsubstate = 'f' AND s.oid = r.srsubid AND s.subfailover
           );
 slots
-------
 {'pg_16394_sync_16385_7394666715149055164'}
(1 row)
</programlisting></para>
   </step>