than the text mode but slightly less robust.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term>
      messages
     </term>
     <listitem>
      <para>
       Boolean option to enable sending the messages that are written
       by <function>pg_logical_emit_message</function>.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term>
      streaming
     </term>
     <listitem>
      <para>
       Boolean option to enable streaming of in-progress transactions.
       It accepts an additional value "parallel" to enable sending extra
       information with some messages to be used for parallelisation.
       Minimum protocol version 2 is required to turn it on.  Minimum protocol
       version 4 is required for the "parallel" option.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term>
      two_phase
     </term>
     <listitem>
      <para>
       Boolean option to enable two-phase transactions.   Minimum protocol
       version 3 is required to turn it on.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry>
     <term>
      origin
     </term>
     <listitem>
      <para>
       Option to send changes by their origin.  Possible values are
       <literal>none</literal> to only send the changes that have no origin
       associated, or <literal>any</literal>
       to send the changes regardless of their origin.  This can be used
       to avoid loops (infinite replication of the same data) among
       replication nodes.
      </para>
     </listitem>
    </varlistentry>
   </variablelist>

  </para>
 </sect2>

 <sect2 id="protocol-logical-messages">
  <title>Logical Replication Protocol Messages</title>

  <para>
   The individual protocol messages are discussed in the following
   subsections. Individual messages are described in
   <xref linkend="protocol-logicalrep-message-formats"/>.
  </para>

  <para>
   All top-level protocol messages begin with a message type byte.
   While represented in code as a character, this is a signed byte with no
   associated encoding.
  </para>

  <para>
   Since the streaming replication protocol supplies a message length there
   is no need for top-level protocol messages to embed a length in their
   header.
  </para>

 </sect2>

 <sect2 id="protocol-logical-messages-flow">
  <title>Logical Replication Protocol Message Flow</title>

  <para>
   With the exception of the <literal>START_REPLICATION</literal> command and
   the replay progress messages, all information flows only from the backend
   to the frontend.
  </para>

  <para>
   The logical replication protocol sends individual transactions one by one.
   This means that all messages between a pair of Begin and Commit messages
   belong to the same transaction. Similarly, all messages between a pair of
   Begin Prepare and Prepare messages belong to the same transaction.
   It also sends changes of large in-progress transactions between a pair of
   Stream Start and Stream Stop messages. The last stream of such a transaction
   contains a Stream Commit or Stream Abort message.
  </para>

  <para>
   Every sent transaction contains zero or more DML messages (Insert,
   Update, Delete). In case of a cascaded setup it can also contain Origin
   messages. The origin message indicates that the transaction originated on
   different replication node. Since a replication node in the scope of logical
   replication protocol can be pretty much anything, the only identifier
   is the origin name. It's downstream's responsibility to handle this as
   needed (if needed). The Origin message is always sent before any DML
   messages in the transaction.
  </para>

  <para>
   Every DML message contains a relation OID, identifying the publisher's
   relation that was acted on.  Before the first DML message for a given
   relation OID, a Relation message will be sent, describing the schema of
   that relation.  Subsequently, a new Relation