lsn    | xid |                    data
-----------+-----+--------------------------------------------
 0/168A060 | 529 | COMMIT PREPARED 'test_prepared1', txid 529
(4 row)

postgres=#-- you can also rollback a prepared transaction
postgres=# BEGIN;
postgres=*# INSERT INTO data(data) VALUES('6');
postgres=*# PREPARE TRANSACTION 'test_prepared2';
postgres=# select * from pg_logical_slot_get_changes('regression_slot', NULL, NULL);
    lsn    | xid |                          data
-----------+-----+---------------------------------------------------------
 0/168A180 | 530 | BEGIN 530
 0/168A1E8 | 530 | table public.data: INSERT: id[integer]:4 data[text]:'6'
 0/168A430 | 530 | PREPARE TRANSACTION 'test_prepared2', txid 530
(3 rows)

postgres=# ROLLBACK PREPARED 'test_prepared2';
postgres=# select * from pg_logical_slot_get_changes('regression_slot', NULL, NULL);
    lsn    | xid |                     data
-----------+-----+----------------------------------------------
 0/168A4B8 | 530 | ROLLBACK PREPARED 'test_prepared2', txid 530
(1 row)
</programlisting>
</sect1>

  <sect1 id="logicaldecoding-explanation">
   <title>Logical Decoding Concepts</title>
   <sect2 id="logicaldecoding-explanation-log-dec">
    <title>Logical Decoding</title>

    <indexterm>
     <primary>Logical Decoding</primary>
    </indexterm>

    <para>
     Logical decoding is the process of extracting all persistent changes
     to a database's tables into a coherent, easy to understand format which
     can be interpreted without detailed knowledge of the database's internal
     state.
    </para>

    <para>
     In <productname>PostgreSQL</productname>, logical decoding is implemented
     by decoding the contents of the <link linkend="wal">write-ahead
     log</link>, which describe changes on a storage level, into an
     application-specific form such as a stream of tuples or SQL statements.
    </para>
   </sect2>

   <sect2 id="logicaldecoding-replication-slots">
    <title>Replication Slots</title>

    <indexterm>
     <primary>replication slot</primary>
     <secondary>logical replication</secondary>
    </indexterm>

    <para>
     In the context of logical replication, a slot represents a stream of
     changes that can be replayed to a client in the order they were made on
     the origin server. Each slot streams a sequence of changes from a single
     database.
    </para>

    <note>
     <para><productname>PostgreSQL</productname> also has streaming replication slots
     (see <xref linkend="streaming-replication"/>), but they are used somewhat
     differently there.
     </para>
    </note>

    <para>
     A replication slot has an identifier that is unique across all databases
     in a <productname>PostgreSQL</productname> cluster. Slots persist
     independently of the connection using them and are crash-safe.
    </para>

    <para>
     A logical slot will emit each change just once in normal operation.
     The current position of each slot is 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