基本的輸出外掛回撥函式（例如 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 表插入但未解碼主表插入。

即使在流式傳輸大事務時，更改仍然按提交順序應用，保持與非流式傳輸模式相同的保證。