この節では論理レプリケーションのプロトコルについて説明します。
このプロトコルはレプリケーションコマンドSTART_REPLICATION SLOT slot_name LOGICALで始まるメッセージフローです。
論理ストリーミングレプリケーションのプロトコルは、物理レプリケーションプロトコルの基本要素の上に構築されています。
PostgreSQLロジカルデコーディングは出力プラグインをサポートしています。
組み込み論理レプリケーションに使用される標準のプラグインはpgoutputです。
START_REPLICATIONコマンドを使用する際、pgoutputは以下のオプションを受け付けます。
プロトコルバージョン。現在1、2、3、および4がサポートされています。
有効なバージョンを指定する必要があります。
バージョン2は、サーババージョン14以降でのみサポートされており、大規模な進行中トランザクションのストリーミングが可能です。
バージョン3はサーババージョン15以降でのみサポートされており、2フェーズコミットのストリーミングが可能です。
バージョン4は、サーババージョン16以降でのみサポートされており、大規模な進行中トランザクションのストリーミングを並行して適用可能です。
サブスクライブする（変更を受け取る）対象となるパブリケーション名をカンマで区切ったリストです。 個々のパブリケーション名は標準的なオブジェクト名と扱われ、必要に応じて引用符で括ることができます。 少なくとも１つのパブリケーション名が必要です。
バイナリ転送モードを使用するブールオプションです。 バイナリモードはテキストモードより高速ですが、堅牢性が少し低くなります。
pg_logical_slot_peek_messageによって書き込まれたメッセージの送信を有効にするブールオプションです。
進行中のトランザクションのストリーミングを有効にするブールオプションです。 並列処理に使用される追加情報の送信を有効にするため、追加の値「parallel」を受け付けます。 本パラメータを有効化するには、プロトコルバージョンが2以上である必要があります。 「parallel」に指定する場合は、プロトコルバージョンが4以上である必要があります。
2相コミットを有効にするブールオプションです。 本パラメータを有効化するには、プロトコルバージョンが3以上である必要があります。
オリジンに応じて変更を送信するオプションです。 取りうる値はオリジンのない変更のみを送信する「none」か、オリジンに関係なく変更を送信する「any」です。 本パラメータはレプリケーションノード間でループ（同じデータの無限の複製）を回避するために使用できます。
個々のプロトコルのメッセージについては以降の副節で説明します。 個々のメッセージについては55.9で説明されています。
トップレベルのプロトコルのメッセージはすべてメッセージタイプのバイトで始まります。 コード内では文字として表現されますが、これは文字符号化のないバイト（符号付き）です。
ストリーミングレプリケーションのプロトコルはメッセージ長を含むため、トップレベルのプロトコルのメッセージはそのヘッダに長さを埋め込む必要がありません。
START_REPLICATIONコマンドと再生進捗のメッセージを除き、すべての情報はバックエンド側からフロントエンド側にのみ流れます。
論理レプリケーションのプロトコルは、個々のトランザクションを一つずつ送信します。 これはつまり、BeginとCommitのメッセージの対の間にある全てのメッセージは同じトランザクションに属するということです。 同様に、Begin PrepareとPrepare messagesの間のすべてのメッセージが同じトランザクションに属しています。 また、ストリーム開始とストリーム終了メッセージの対の間の大きな継続中トランザクションの変更を送信します。 そのようなトランザクションの最後のストリームは、ストリームコミットあるいはストリームアボートメッセージを含んでいます。
送信されるすべてのトランザクションにはゼロ個以上のDMLメッセージ（Insert、Update、Delete）が含まれます。 カスケードの設定がされている場合は、Originメッセージを含めることができます。 Originメッセージはトランザクションの起点が別のレプリケーションノードであることを示します。 論理レプリケーションのプロトコルという観点では、レプリケーションノードはほぼ何でも良いため、唯一の識別子はOriginの名前です。 （必要なら）必要に応じてこれを処理するのは下流側の責任です。 Originメッセージは必ずトランザクション内のどのDMLよりも前に送信されます。
すべてのDMLメッセージには、パブリッシャーが処理していたリレーションOIDが含まれています。 指定されたリレーションOIDの最初DMLメッセージの前に、リレーションのスキーマを記述するリレーションメッセージが送られます。 最後に送信されたリレーションメッセージ以降にリレーションの定義が変更されていたら、続いて新しいリレーションメッセージが送信されます。 （必要なだけクライアントはこのメタデータを記憶できるとプロトコルは見なしています。）
リレーションメッセージはOIDによって列型を識別します。 組み込みの型では、クライアントはローカルに型OIDを検索できると見なされ、追加のデータは必要ありません。 組み込み以外の型OIDでは、OIDに紐づく型名を提供するために、リレーションメッセージの前に型メッセージが送られます。 したがって、リレーションの列の型を特に識別する必要のあるクライアントは、型メッセージの内容をキャッシュし、型OIDがキャッシュにあるかどうかまずキャッシュを調べるべきです。 もしなければ、ローカルでその型OIDを調べます。