基本的输出插件回调（例如，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 表插入，但没有解码主表插入。

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