<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
     disabled subscription, then the subscription cannot be resumed after
     failover even when it is enabled.
    </para>

    <para>
     To resume logical replication after failover from the synced logical
     slots, the subscription's 'conninfo' must be altered to point to the
     new primary server. This is done using
     <link linkend="sql-altersubscription-params-connection"><command>ALTER SUBSCRIPTION ... CONNECTION</command></link>.
     It is recommended that subscriptions are first disabled before promoting
     the standby and are re-enabled after altering the connection string.
    </para>
    <caution>
     <para>
      There is a chance that the old primary is up again during the promotion
      and if subscriptions are not disabled, the logical subscribers may
      continue to receive data from the old primary server even after promotion
      until the connection string is altered. This might result in data
      inconsistency issues, preventing the logical subscribers from being
      able to continue replication from the new primary server.
     </para>
    </caution>
   </sect2>

   <sect2 id="logicaldecoding-explanation-output-plugins">
    <title>Output Plugins</title>
    <para>
     Output plugins transform the data from the write-ahead log's internal
     representation into the format the consumer of a replication slot desires.
    </para>
   </sect2>

   <sect2 id="logicaldecoding-explanation-exported-snapshots">
    <title>Exported Snapshots</title>
    <para>
     When a new replication slot is created using the streaming replication
     interface (see <xref linkend="protocol-replication-create-replication-slot"/>), a
     snapshot is exported
     (see <xref linkend="functions-snapshot-synchronization"/>), which will show
     exactly the state of the database after which all changes will be
     included in the change stream. This can be used to create a new replica by
     using <link linkend="sql-set-transaction"><literal>SET TRANSACTION
     SNAPSHOT</literal></link> to read the state of the database at the moment
     the slot was created. This transaction can then be used to dump the
     database's state at that point in time, which afterwards can be updated
     using the slot's contents without losing any changes.
    </para>
    <para>
     Applications that do not require
     snapshot export may suppress it with the <literal>SNAPSHOT 'nothing'</literal>
     option.
    </para>
   </sect2>
  </sect1>

  <sect1 id="logicaldecoding-walsender">
   <title>Streaming Replication Protocol Interface</title>

   <para>
    The commands
    <itemizedlist>
     <listitem>
      <para><literal>CREATE_REPLICATION_SLOT <replaceable>slot_name</replaceable> LOGICAL <replaceable>output_plugin</replaceable></literal></para>
     </listitem>

     <listitem>
      <para><literal>DROP_REPLICATION_SLOT <replaceable>slot_name</replaceable></literal> <optional> <literal>WAIT</literal> </optional></para>