decoded
    changes are transmitted, the transaction can be committed using the
    <function>stream_commit_cb</function> callback
    (or possibly aborted using the <function>stream_abort_cb</function> callback).
    If two-phase commits are supported, the transaction can be prepared using the
    <function>stream_prepare_cb</function> callback,
    <command>COMMIT PREPARED</command> using the
    <function>commit_prepared_cb</function> callback or aborted using the
    <function>rollback_prepared_cb</function>.
   </para>

   <para>
    One example sequence of streaming callback calls for one transaction may
    look like this:
<programlisting>
stream_start_cb(...);   &lt;-- start of first block of changes
  stream_change_cb(...);
  stream_change_cb(...);
  stream_message_cb(...);
  stream_change_cb(...);
  ...
  stream_change_cb(...);
stream_stop_cb(...);    &lt;-- end of first block of changes

stream_start_cb(...);   &lt;-- start of second block of changes
  stream_change_cb(...);
  stream_change_cb(...);
  stream_change_cb(...);
  ...
  stream_message_cb(...);
  stream_change_cb(...);
stream_stop_cb(...);    &lt;-- end of second block of changes


[a. when using normal commit]
stream_commit_cb(...);    &lt;-- commit of the streamed transaction

[b. when using two-phase commit]
stream_prepare_cb(...);   &lt;-- prepare the streamed transaction
commit_prepared_cb(...);  &lt;-- commit of the prepared transaction
</programlisting>
   </para>

   <para>
    The actual sequence of callback calls may be more complicated, of course.
    There may be blocks for multiple streamed transactions, some of the
    transactions may get aborted, etc.
   </para>

   <para>
    Similar to spill-to-disk behavior, streaming is triggered when the total
    amount of changes decoded from the WAL (for all in-progress transactions)
    exceeds the limit defined by <varname>logical_decoding_work_mem</varname> setting.
    At that point, the largest top-level transaction (measured by the amount of memory
    currently used for decoded changes) is selected and streamed.  However, in
    some cases we still have to spill to disk even if streaming is enabled
    because we exceed the memory threshold but still have not decoded the
    complete tuple e.g., only decoded toast table insert but not the main table
    insert.
   </para>

   <para>
    Even when streaming large transactions, the changes are still applied in
    commit order, preserving the same guarantees as the non-streaming mode.
   </para>

  </sect1>

  <sect1 id="logicaldecoding-two-phase-commits">
   <title>Two-phase Commit Support for Logical Decoding</title>

   <para>
    With the basic output plugin callbacks (eg., <function>begin_cb</function>,
    <function>change_cb</function>, <function>commit_cb</function> and
    <function>message_cb</function>) two-phase commit commands like
    <command>PREPARE TRANSACTION</command>, <command>COMMIT PREPARED</command>