persisted only at checkpoint, so in
     the case of a crash the slot may return to an earlier LSN, which will
     then cause recent changes to be sent again when the server restarts.
     Logical decoding clients are responsible for avoiding ill effects from
     handling the same message more than once.  Clients may wish to record
     the last LSN they saw when decoding and skip over any repeated data or
     (when using the replication protocol) request that decoding start from
     that LSN rather than letting the server determine the start point.
     The Replication Progress Tracking feature is designed for this purpose,
     refer to <link linkend="replication-origins">replication origins</link>.
    </para>

    <para>
     Multiple independent slots may exist for a single database. Each slot has
     its own state, allowing different consumers to receive changes from
     different points in the database change stream. For most applications, a
     separate slot will be required for each consumer.
    </para>

    <para>
     A logical replication slot knows nothing about the state of the
     receiver(s).  It's even possible to have multiple different receivers using
     the same slot at different times; they'll just get the changes following
     on from when the last receiver stopped consuming them. Only one receiver
     may consume changes from a slot at any given time.
    </para>

    <para>
     A logical replication slot can also be created on a hot standby. To prevent
     <command>VACUUM</command> from removing required rows from the system
     catalogs, <varname>hot_standby_feedback</varname> should be set on the
     standby. In spite of that, if any required rows get removed, the slot gets
     invalidated. It's highly recommended to use a physical slot between the
     primary and the standby. Otherwise, <varname>hot_standby_feedback</varname>
     will work but only while the connection is alive (for example a node
     restart would break it). Then, the primary may delete system catalog rows
     that could be needed by the logical decoding on the standby (as it does
     not know about the <literal>catalog_xmin</literal> on the standby).
     Existing logical slots on standby also get invalidated if
     <varname>wal_level</varname> on the primary is reduced to less than
     <literal>logical</literal>.
     This is done as soon as the standby detects such a change in the WAL stream.
     It means that, for walsenders that are lagging (if any), some WAL records up
     to the <varname>wal_level</varname> parameter change on the primary won't be
     decoded.
    </para>

    <para>
     Creation of a logical slot requires information about all the currently
     running transactions. On the primary, this information is available
     directly, but on a standby, this information has to be obtained from
     primary. Thus, slot creation may need to wait for some activity to happen
     on the primary. If the primary is idle, 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>