The basic output plugin callbacks (e.g., <function>begin_cb</function>, <function>change_cb</function>, <function>commit_cb</function> and <function>message_cb</function>) are only invoked when the transaction actually commits. The changes are still decoded from the transaction log, but are only passed to the output plugin at commit (and discarded if the transaction aborts). 基本的な出力プラグインコールバック(begin_cb、change_cb、commit_cb、message_cbなど)は、トランザクションが実際にコミットしたときにのみ呼び出されます。 変更はトランザクションログからデコードされますが、コミット時に出力プラグインに渡されるだけです(トランザクションがアボートした場合は破棄されます)。

This means that while the decoding happens incrementally, and may spill to disk to keep memory usage under control, all the decoded changes have to be transmitted when the transaction finally commits (or more precisely, when the commit is decoded from the transaction log). Depending on the size of the transaction and network bandwidth, the transfer time may significantly increase the apply lag. つまり、デコードは増分的に行われ、メモリー使用量を制御するためにディスクにオーバーフローする場合がありますが、デコードされたすべての変更は、トランザクションが最終的にコミットされたとき(より正確には、コミットがトランザクションログからデコードされたとき)に送信される必要があります。 トランザクションおよびネットワーク帯域幅のサイズによっては、転送時間によって適用ラグが大幅に増加する場合があります。

To reduce the apply lag caused by large transactions, an output plugin may provide additional callback to support incremental streaming of in-progress transactions. There are multiple required streaming callbacks (<function>stream_start_cb</function>, <function>stream_stop_cb</function>, <function>stream_abort_cb</function>, <function>stream_commit_cb</function> and <function>stream_change_cb</function>) and two optional callbacks (<function>stream_message_cb</function> and <function>stream_truncate_cb</function>). Also, if streaming of two-phase commands is to be supported, then additional callbacks must be provided. (See <xref linkend="logicaldecoding-two-phase-commits"/> for details). 大規模なトランザクションによって発生する適用遅延を軽減するために、出力プラグインは、継続中のトランザクションの増分ストリーミングをサポートする追加のコールバックを提供できます。 複数の必要なストリーミングコールバック(stream_start_cb、stream_stop_cb、stream_abort_cb、stream_commit_cbおよびstream_change_cb)と2つのオプションのコールバック(stream_message_cbおよびstream_truncate_cb)があります。 2相コマンドのストリーミングをサポートする場合は、追加のコールバックを提供する必要があります（詳細は49.10を参照してください）。

When streaming an in-progress transaction, the changes (and messages) are streamed in blocks demarcated by <function>stream_start_cb</function> and <function>stream_stop_cb</function> callbacks. Once all the decoded changes are transmitted, the transaction can be committed using the <function>stream_commit_cb</function> callback (or possibly aborted using the <function>stream_abort_cb</function> callback). If two-phase commits are supported, the transaction can be prepared using the <function>stream_prepare_cb</function> callback, <command>COMMIT PREPARED</command> using the <function>commit_prepared_cb</function> callback or aborted using the <function>rollback_prepared_cb</function>. 継続中のトランザクションをストリーミングする場合、変更(およびメッセージ)はstream_start_cbおよびstream_stop_cbコールバックで区切られたブロックでストリーミングされます。 デコードされたすべての変更が送信されると、トランザクションはstream_commit_cbコールバックを使用してコミットできます(またはstream_abort_cbコールバックを使用してアボートできます)。 2相コミットがサポートされている場合、トランザクションはstream_prepare_cbコールバックを使用して準備できます。 COMMIT PREPAREDはcommit_prepared_cbコールバックを使用して準備できます。 またはrollback_prepared_cbを使用してアボートできます。

One example sequence of streaming callback calls for one transaction may look like this: 1つのトランザクションに対するストリーミングコールバック呼び出しのシーケンスの例は、次のようになります。

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

The actual sequence of callback calls may be more complicated, of course. There may be blocks for multiple streamed transactions, some of the transactions may get aborted, etc. もちろん、実際のコールバック呼び出しのシーケンスはもっと複雑かもしれません。 ストリーム化された複数のトランザクションにブロックがあったり、一部のトランザクションがアボートされたりするなどです。

Similar to spill-to-disk behavior, streaming is triggered when the total amount of changes decoded from the WAL (for all in-progress transactions) exceeds the limit defined by <varname>logical_decoding_work_mem</varname> setting. At that point, the largest top-level transaction (measured by the amount of memory currently used for decoded changes) is selected and streamed. However, in some cases we still have to spill to disk even if streaming is enabled because we exceed the memory threshold but still have not decoded the complete tuple e.g., only decoded toast table insert but not the main table insert. ディスクへのスピル動作と同様に、ストリーミングは、WALからデコードされた変更の合計量(すべての継続中のトランザクションについて)がlogical_decoding_work_mem設定で定義された制限を超えたときにトリガされます。 その時点で、最大のトップレベルトランザクション(デコードされた変更に現在使用されているメモリ量で測定されます)が選択され、ストリーミングされます。 ただし、場合によっては、ストリーミングが有効になっていても、メモリしきい値を超えても完全なタプルがまだデコードされていない(例えば、メインテーブルの挿入ではなくトーストテーブルの挿入のみがデコードされているなど)ため、ディスクへのスピルが必要になることがあります。

Even when streaming large transactions, the changes are still applied in commit order, preserving the same guarantees as the non-streaming mode. 大規模なトランザクションをストリーミングする場合でも、変更はコミット順に適用され、非ストリーミングモードと同じ保証が維持されます。