Using the <literal>START_REPLICATION</literal> command, <literal>pgoutput</literal> accepts the following options: START_REPLICATIONコマンドを使用する際、pgoutputは以下のオプションを受け付けます。

The individual protocol messages are discussed in the following subsections. Individual messages are described in <xref linkend="protocol-logicalrep-message-formats"/>. 個々のプロトコルのメッセージについては以降の副節で説明します。 個々のメッセージについては53.9で説明されています。

All top-level protocol messages begin with a message type byte. While represented in code as a character, this is a signed byte with no associated encoding. トップレベルのプロトコルのメッセージはすべてメッセージタイプのバイトで始まります。 コード内では文字として表現されますが、これは文字符号化のないバイト（符号付き）です。

Since the streaming replication protocol supplies a message length there is no need for top-level protocol messages to embed a length in their header. ストリーミングレプリケーションのプロトコルはメッセージ長を含むため、トップレベルのプロトコルのメッセージはそのヘッダに長さを埋め込む必要がありません。

With the exception of the <literal>START_REPLICATION</literal> command and the replay progress messages, all information flows only from the backend to the frontend. START_REPLICATIONコマンドと再生進捗のメッセージを除き、すべての情報はバックエンド側からフロントエンド側にのみ流れます。

The logical replication protocol sends individual transactions one by one. This means that all messages between a pair of Begin and Commit messages belong to the same transaction. Similarly, all messages between a pair of Begin Prepare and Prepare messages belong to the same transaction. It also sends changes of large in-progress transactions between a pair of Stream Start and Stream Stop messages. The last stream of such a transaction contains a Stream Commit or Stream Abort message. 論理レプリケーションのプロトコルは、個々のトランザクションを一つずつ送信します。 これはつまり、BeginとCommitのメッセージの対の間にある全てのメッセージは同じトランザクションに属するということです。 同様に、Begin PrepareとPrepare messagesの間のすべてのメッセージが同じトランザクションに属しています。 また、ストリーム開始とストリーム終了メッセージの対の間の大きな継続中トランザクションの変更を送信します。 そのようなトランザクションの最後のストリームは、ストリームコミットあるいはストリームアボートメッセージを含んでいます。

Every sent transaction contains zero or more DML messages (Insert, Update, Delete). In case of a cascaded setup it can also contain Origin messages. The origin message indicates that the transaction originated on different replication node. Since a replication node in the scope of logical replication protocol can be pretty much anything, the only identifier is the origin name. It's downstream's responsibility to handle this as needed (if needed). The Origin message is always sent before any DML messages in the transaction. 送信されるすべてのトランザクションにはゼロ個以上のDMLメッセージ（Insert、Update、Delete）が含まれます。 カスケードの設定がされている場合は、Originメッセージを含めることができます。 Originメッセージはトランザクションの起点が別のレプリケーションノードであることを示します。 (訳注：原文が文法的におかしく、構文解析不能でした。 "indicated"は"indicates"、"originated"は"originates"であるとして、 また、 different"の前に"a"があるものとして訳しました。) 論理レプリケーションのプロトコルという観点では、レプリケーションノードはほぼ何でも良いため、唯一の識別子はOriginの名前です。 （必要なら）必要に応じてこれを処理するのは下流側の責任です。 Originメッセージは必ずトランザクション内のどのDMLよりも前に送信されます。

Every DML message contains a relation OID, identifying the publisher's relation that was acted on. Before the first DML message for a given relation OID, a Relation message will be sent, describing the schema of that relation. Subsequently, a new Relation message will be sent if the relation's definition has changed since the last Relation message was sent for it. (The protocol assumes that the client is capable of remembering this metadata for as many relations as needed.) すべてのDMLメッセージには、パブリッシャーが処理していたリレーションOIDが含まれています。 指定されたリレーションOIDの最初DMLメッセージの前に、リレーションのスキーマを記述するリレーションメッセージが送られます。 最後に送信されたリレーションメッセージ以降にリレーションの定義が変更されていたら、続いて新しいリレーションメッセージが送信されます。 （必要なだけクライアントはこのメタデータを記憶できるとプロトコルは見なしています。）

Relation messages identify column types by their OIDs. In the case of a built-in type, it is assumed that the client can look up that type OID locally, so no additional data is needed. For a non-built-in type OID, a Type message will be sent before the Relation message, to provide the type name associated with that OID. Thus, a client that needs to specifically identify the types of relation columns should cache the contents of Type messages, and first consult that cache to see if the type OID is defined there. If not, look up the type OID locally. リレーションメッセージはOIDによって列型を識別します。 組み込みの型では、クライアントはローカルに型OIDを検索できると見なされ、追加のデータは必要ありません。 組み込み以外の型OIDでは、OIDに紐づく型名を提供するために、リレーションメッセージの前に型メッセージが送られます。 したがって、リレーションの列の型を特に識別する必要のあるクライアントは、型メッセージの内容をキャッシュし、型OIDがキャッシュにあるかどうかまずキャッシュを調べるべきです。 もしなければ、ローカルでその型OIDを調べます。