基本的輸出外掛程式回呼函數（例如，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 表的插入，但沒有解碼主表的插入。

即使在串流大型交易時，變更仍然以提交順序應用，保留與非串流模式相同的保證。