基本输出插件回调（例如，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.10 节）。

在流式传输正在进行的事务时，更改（和消息）以由 stream_start_cb 和 stream_stop_cb 回调分隔的块进行流式传输。一旦所有解码的更改都已传输，就可以使用 stream_commit_cb 回调提交事务（或者可能使用 stream_abort_cb 回调中止事务）。如果支持两阶段提交，则可以使用 stream_prepare_cb 回调准备事务，使用 commit_prepared_cb 回调 COMMIT PREPARED 或使用 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 表的插入，但尚未解码主表的插入。

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