論理レプリケーションのSTART_REPLICATIONコマンドは以下のパラメータを受け付けます。

個々のプロトコルのメッセージについては以降の副節で説明します。 個々のメッセージについては53.9で説明されています。

トップレベルのプロトコルのメッセージはすべてメッセージタイプのバイトで始まります。 コード内では文字として表現されますが、これは文字符号化のないバイト（符号付き）です。

ストリーミングレプリケーションのプロトコルはメッセージ長を含むため、トップレベルのプロトコルのメッセージはそのヘッダに長さを埋め込む必要がありません。

START_REPLICATIONコマンドと再生進捗のメッセージを除き、すべての情報はバックエンド側からフロントエンド側にのみ流れます。

論理レプリケーションのプロトコルは、個々のトランザクションを一つずつ送信します。 これはつまり、BeginとCommitのメッセージの対の間にある全てのメッセージは同じトランザクションに属するということです。 また、ストリーム開始とストリーム終了メッセージの対の間の大きな継続中トランザクションの変更を送信します。 そのようなトランザクションの最後のストリームは、ストリームコミットあるいはストリームアボートメッセージを含んでいます。

送信されるすべてのトランザクションにはゼロ個以上のDMLメッセージ（Insert、Update、Delete）が含まれます。 カスケードの設定がされている場合は、Originメッセージを含めることができます。 Originメッセージはトランザクションの起点が別のレプリケーションノードであることを示します。 論理レプリケーションのプロトコルという観点では、レプリケーションノードはほぼ何でも良いため、唯一の識別子はOriginの名前です。 （必要なら）必要に応じてこれを処理するのは下流側の責任です。 Originメッセージは必ずトランザクション内のどのDMLよりも前に送信されます。

すべてのDMLメッセージには、パブリッシャーが処理していたリレーションOIDが含まれています。 指定されたリレーションOIDの最初DMLメッセージの前に、リレーションのスキーマを記述するリレーションメッセージが送られます。 最後に送信されたリレーションメッセージ以降にリレーションの定義が変更されていたら、続いて新しいリレーションメッセージが送信されます。 （必要なだけクライアントはこのメタデータを記憶できるとプロトコルは見なしています。）

リレーションメッセージはOIDによって列型を識別します。 組み込みの型では、クライアントはローカルに型OIDを検索できると見なされ、追加のデータは必要ありません。 組み込み以外の型OIDでは、OIDに紐づく型名を提供するために、リレーションメッセージの前に型メッセージが送られます。 したがって、リレーションの列の型を特に識別する必要のあるクライアントは、型メッセージの内容をキャッシュし、型OIDがキャッシュにあるかどうかまずキャッシュを調べるべきです。 もしなければ、ローカルでその型OIDを調べます。