creating a logical slot on
     standby may take noticeable time. This can be sped up by calling the
     <function>pg_log_standby_snapshot</function> function on the primary.
    </para>

    <caution>
     <para>
      Replication slots persist across crashes and know nothing about the state
      of their consumer(s). They will prevent removal of required resources
      even when there is no connection using them. This consumes storage
      because neither required WAL nor required rows from the system catalogs
      can be removed by <command>VACUUM</command> as long as they are required by a replication
      slot.  In extreme cases this could cause the database to shut down to prevent
      transaction ID wraparound (see <xref linkend="vacuum-for-wraparound"/>).
      So if a slot is no longer required it should be dropped.
     </para>
    </caution>

   </sect2>

   <sect2 id="logicaldecoding-replication-slots-synchronization">
    <title>Replication Slot Synchronization</title>
    <para>
     The logical replication slots on the primary can be synchronized to
     the hot standby by using the <literal>failover</literal> parameter of
     <link linkend="pg-create-logical-replication-slot">
     <function>pg_create_logical_replication_slot</function></link>, or by
     using the <link linkend="sql-createsubscription-params-with-failover">
     <literal>failover</literal></link> option of
     <command>CREATE SUBSCRIPTION</command> during slot creation, and then calling
     <link linkend="pg-sync-replication-slots">
     <function>pg_sync_replication_slots</function></link>
     on the standby. By setting <link linkend="guc-sync-replication-slots">
     <varname>sync_replication_slots</varname></link>
     on the standby, the failover slots can be synchronized periodically in
     the slotsync worker. For the synchronization to work, it is mandatory to
     have a physical replication slot between the primary and the standby (i.e.,
     <link linkend="guc-primary-slot-name"><varname>primary_slot_name</varname></link>
     should be configured on the standby), and
     <link linkend="guc-hot-standby-feedback"><varname>hot_standby_feedback</varname></link>
     must be enabled on the standby. It is also necessary to specify a valid
     <literal>dbname</literal> in the
     <link linkend="guc-primary-conninfo"><varname>primary_conninfo</varname></link>.
     It's highly recommended that the said physical replication slot is named in
     <link linkend="guc-synchronized-standby-slots"><varname>synchronized_standby_slots</varname></link>
     list on the primary, to prevent the subscriber from consuming changes
     faster than the hot standby. Even when correctly configured, some latency
     is expected when sending changes to logical subscribers due to the waiting
     on slots named in
     <link linkend="guc-synchronized-standby-slots"><varname>synchronized_standby_slots</varname></link>.
     When <varname>synchronized_standby_slots</varname> is utilized, the
     primary server will not completely shut down until the corresponding
     standbys, associated with the physical replication slots specified
     in <varname>synchronized_standby_slots</varname>, have confirmed
     receiving the WAL up to the latest flushed position on the primary server.
    </para>

    <para>
     The ability to resume logical replication after failover depends upon the
     <link linkend="view-pg-replication-slots">pg_replication_slots</link>.<structfield>synced</structfield>
     value for the synchronized slots on the standby at the time of failover.
     Only persistent slots that have attained synced state as true on the standby
     before failover can be used for logical replication after failover.
     Temporary synced slots cannot be used for logical decoding, therefore
     logical replication for those slots cannot be resumed. For example, if the
     synchronized slot could not become persistent on the standby due to a