基本输出插件回调（例如 begin_cb、change_cb、commit_cb 和 message_cb）只会在事务实际提交时被调用。更改仍然会从事务日志中解码出来，但只有在提交时才会传给输出插件（如果事务中止，则会被丢弃）。

这意味着，虽然解码是增量进行的，并且可能会溢写到磁盘以便控制内存使用，但当事务最终提交时（更准确地说，当从事务日志中解码到该提交时），所有已解码的更改都必须被传输出去。根据事务大小和网络带宽，传输时间可能会显著增加应用滞后。

为了减少大事务造成的应用滞后，输出插件可以提供额外的回调，以支持对进行中事务进行增量流式传输。必需的流式传输回调有多个：stream_start_cb、stream_stop_cb、stream_abort_cb、stream_commit_cb 和 stream_change_cb；另有两个可选回调：stream_message_cb 和 stream_truncate_cb。此外，如果还要支持两阶段命令的流式传输，则必须额外提供相关回调。（详见第 47.11 节。）

在流式传输进行中事务时，更改（以及消息）会按由 stream_start_cb 和 stream_stop_cb 回调界定的块进行传送。一旦所有解码出的更改都已传输，事务就可以通过 stream_commit_cb 回调来提交（或者可能通过 stream_abort_cb 回调来中止）。如果支持两阶段提交，事务可以使用 stream_prepare_cb 回调进入预备状态，随后在 COMMIT PREPARED 时通过 commit_prepared_cb 回调提交，或者通过 rollback_prepared_cb 回调中止。

某个事务的一组流式回调调用示例可能如下：

stream_start_cb(...);   <-- start of first block of changes
  stream_change_cb(...);
  stream_change_cb(...);
  stream_message_cb(...);
  stream_change_cb(...);
  ...
  stream_change_cb(...);
stream_stop_cb(...);    <-- end of first block of changes

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


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

[b. when using two-phase commit]
stream_prepare_cb(...);   <-- prepare the streamed transaction
commit_prepared_cb(...);  <-- commit of the prepared transaction

当然，回调调用的实际顺序可能会更复杂。可能会有多个流式事务的块，其中一些事务也可能会被中止，等等。

与溢写到磁盘的行为类似，当从 WAL 中解码出的更改总量（针对所有进行中事务）超过 logical_decoding_work_mem 设置定义的限制时，就会触发流式传输。此时，会选择最大的顶层事务（按当前用于已解码更改的内存量衡量）并进行流式传输。不过，在某些情况下，即使启用了流式传输，我们仍然必须溢写到磁盘，因为虽然超过了内存阈值，但还没有解码出完整的元组，例如只解码了 TOAST 表插入，而没有解码主表插入。

即使在流式传输大事务时，更改仍然会按提交顺序应用，从而保留与非流式传输模式相同的保证。