{"Entry":{"collection":"decode","key":"pgoutput","name":"pgoutput","aliases":[],"metadata":{"aliases":[],"category":"Core replication","content_hash":"1988aae57b9e4ed3ba61ac20f8b6bffbdb067f30880742d4e9b4ecb4d3d667cc","imported_at":"2026-09-30T00:40:37.257019+08:00","name":"pgoutput","name_zh":"Core replication","slug":"pgoutput","summary":"The built-in output plugin used by PostgreSQL logical replication."}},"Definition":{"Collection":"decode","Key":"pgoutput","SourceDatabase":"center","Version":"18","SourceTable":"logical_decoding_plugin","SourceKey":"pgoutput","SourceRevision":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","Facts":{"callbacks":{"begin_cb":"pgoutput_begin_txn","begin_prepare_cb":"pgoutput_begin_prepare_txn","change_cb":"pgoutput_change","commit_cb":"pgoutput_commit_txn","commit_prepared_cb":"pgoutput_commit_prepared_txn","filter_by_origin_cb":"pgoutput_origin_filter","message_cb":"pgoutput_message","prepare_cb":"pgoutput_prepare_txn","rollback_prepared_cb":"pgoutput_rollback_prepared_txn","shutdown_cb":"pgoutput_shutdown","startup_cb":"pgoutput_startup","stream_abort_cb":"pgoutput_stream_abort","stream_change_cb":"pgoutput_change","stream_commit_cb":"pgoutput_stream_commit","stream_message_cb":"pgoutput_message","stream_prepare_cb":"pgoutput_stream_prepare_txn","stream_start_cb":"pgoutput_stream_start","stream_stop_cb":"pgoutput_stream_stop","stream_truncate_cb":"pgoutput_truncate","truncate_cb":"pgoutput_truncate"},"comparison_data":{"callbacks":{"begin_cb":"pgoutput_begin_txn","begin_prepare_cb":"pgoutput_begin_prepare_txn","change_cb":"pgoutput_change","commit_cb":"pgoutput_commit_txn","commit_prepared_cb":"pgoutput_commit_prepared_txn","filter_by_origin_cb":"pgoutput_origin_filter","message_cb":"pgoutput_message","prepare_cb":"pgoutput_prepare_txn","rollback_prepared_cb":"pgoutput_rollback_prepared_txn","shutdown_cb":"pgoutput_shutdown","startup_cb":"pgoutput_startup","stream_abort_cb":"pgoutput_stream_abort","stream_change_cb":"pgoutput_change","stream_commit_cb":"pgoutput_stream_commit","stream_message_cb":"pgoutput_message","stream_prepare_cb":"pgoutput_stream_prepare_txn","stream_start_cb":"pgoutput_stream_start","stream_stop_cb":"pgoutput_stream_stop","stream_truncate_cb":"pgoutput_truncate","truncate_cb":"pgoutput_truncate"},"options":[{"definition":"Protocol version. Currently versions 1 , 2 , 3 , and 4 are supported. A valid version is required. Version 2 is supported only for server version 14 and above, and it allows streaming of large in-progress transactions. Version 3 is supported only for server version 15 and above, and it allows streaming of two-phase commits. Version 4 is supported only for server version 16 and above, and it allows streams of large in-progress transactions to be applied in parallel.","name":"proto_version"},{"definition":"Comma-separated list of publication names for which to subscribe (receive changes). The individual publication names are treated as standard objects names and can be quoted the same as needed. At least one publication name is required.","name":"publication_names"},{"definition":"Boolean option to use binary transfer mode. Binary mode is faster than the text mode but slightly less robust.","name":"binary"},{"definition":"Boolean option to enable sending the messages that are written by pg_logical_emit_message .","name":"messages"},{"definition":"Option to enable streaming of in-progress transactions. Valid values are off (the default), on and parallel . The setting parallel enables sending extra information with some messages to be used for parallelization. Minimum protocol version 2 is required to turn it on . Minimum protocol version 4 is required for the parallel value.","name":"streaming"},{"definition":"Boolean option to enable two-phase transactions. Minimum protocol version 3 is required to turn it on.","name":"two_phase"},{"definition":"Option to send changes by their origin. Possible values are none to only send the changes that have no origin associated, or any to send the changes regardless of their origin. This can be used to avoid loops (infinite replication of the same data) among replication nodes.","name":"origin"}],"protocol_versions":{"LOGICALREP_PROTO_MIN_VERSION_NUM":"1","LOGICALREP_PROTO_STREAM_PARALLEL_VERSION_NUM":"4","LOGICALREP_PROTO_STREAM_VERSION_NUM":"2","LOGICALREP_PROTO_TWOPHASE_VERSION_NUM":"3","LOGICALREP_PROTO_VERSION_NUM":"1"},"source_options":["binary","messages","origin","proto_version","publication_names","streaming","two_phase"]},"comparison_hash":"825d73cfabb72ac9c0d2de837bc79ea972bb82f3c010a3833852f3f7e9e3935a","description":["The built-in output plugin used by PostgreSQL logical replication."],"evidence_kind":"source and documentation","facts":[{"label":"Interface family","value":"Logical-decoding output plugin"},{"label":"Handler or routine","value":"_PG_output_plugin_init"},{"label":"Recorded callbacks","value":"20"},{"label":"LOGICALREP_PROTO_MIN_VERSION_NUM","value":"1"},{"label":"LOGICALREP_PROTO_VERSION_NUM","value":"1"},{"label":"LOGICALREP_PROTO_STREAM_VERSION_NUM","value":"2"},{"label":"LOGICALREP_PROTO_TWOPHASE_VERSION_NUM","value":"3"},{"label":"LOGICALREP_PROTO_STREAM_PARALLEL_VERSION_NUM","value":"4"}],"manual_html":"\u003cdiv class=\"sect1\" id=\"PROTOCOL-LOGICAL-REPLICATION\"\u003e\n\u003cdiv class=\"titlepage\"\u003e\n\u003cdiv\u003e\n\u003cdiv\u003e\n\u003ch2 class=\"title\"\u003e54.5. Logical Streaming Replication Protocol \u003c/h2\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\n\u003cp\u003eThis section describes the logical replication protocol, which is the message flow started by the \u003ccode class=\"literal\"\u003eSTART_REPLICATION\u003c/code\u003e \u003ccode class=\"literal\"\u003eSLOT\u003c/code\u003e \u003cem class=\"replaceable\"\u003e\u003ccode\u003eslot_name\u003c/code\u003e\u003c/em\u003e \u003ccode class=\"literal\"\u003eLOGICAL\u003c/code\u003e replication command.\u003c/p\u003e\n\u003cp\u003eThe logical streaming replication protocol builds on the primitives of the physical streaming replication protocol.\u003c/p\u003e\n\u003cp\u003e\u003cspan class=\"productname\"\u003ePostgreSQL\u003c/span\u003e logical decoding supports output plugins. \u003ccode class=\"literal\"\u003epgoutput\u003c/code\u003e is the standard one used for the built-in logical replication.\u003c/p\u003e\n\u003cdiv class=\"sect2\" id=\"PROTOCOL-LOGICAL-REPLICATION-PARAMS\"\u003e\n\u003cdiv class=\"titlepage\"\u003e\n\u003cdiv\u003e\n\u003cdiv\u003e\n\u003ch3 class=\"title\"\u003e54.5.1. Logical Streaming Replication Parameters \u003c/h3\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\u003cp\u003eUsing the \u003ccode class=\"literal\"\u003eSTART_REPLICATION\u003c/code\u003e command, \u003ccode class=\"literal\"\u003epgoutput\u003c/code\u003e accepts the following options:\u003c/p\u003e\n\u003cdiv class=\"variablelist\"\u003e\n\u003cdl class=\"variablelist\"\u003e\n\u003cdt\u003e\u003cspan class=\"term\"\u003eproto_version\u003c/span\u003e\u003c/dt\u003e\n\u003cdd\u003e\n\u003cp\u003eProtocol version. Currently versions \u003ccode class=\"literal\"\u003e1\u003c/code\u003e, \u003ccode class=\"literal\"\u003e2\u003c/code\u003e, \u003ccode class=\"literal\"\u003e3\u003c/code\u003e, and \u003ccode class=\"literal\"\u003e4\u003c/code\u003e are supported. A valid version is required.\u003c/p\u003e\n\u003cp\u003eVersion \u003ccode class=\"literal\"\u003e2\u003c/code\u003e is supported only for server version 14 and above, and it allows streaming of large in-progress transactions.\u003c/p\u003e\n\u003cp\u003eVersion \u003ccode class=\"literal\"\u003e3\u003c/code\u003e is supported only for server version 15 and above, and it allows streaming of two-phase commits.\u003c/p\u003e\n\u003cp\u003eVersion \u003ccode class=\"literal\"\u003e4\u003c/code\u003e is supported only for server version 16 and above, and it allows streams of large in-progress transactions to be applied in parallel.\u003c/p\u003e\n\u003c/dd\u003e\n\u003cdt\u003e\u003cspan class=\"term\"\u003epublication_names\u003c/span\u003e\u003c/dt\u003e\n\u003cdd\u003e\n\u003cp\u003eComma-separated list of publication names for which to subscribe (receive changes). The individual publication names are treated as standard objects names and can be quoted the same as needed. At least one publication name is required.\u003c/p\u003e\n\u003c/dd\u003e\n\u003cdt\u003e\u003cspan class=\"term\"\u003ebinary\u003c/span\u003e\u003c/dt\u003e\n\u003cdd\u003e\n\u003cp\u003eBoolean option to use binary transfer mode. Binary mode is faster than the text mode but slightly less robust.\u003c/p\u003e\n\u003c/dd\u003e\n\u003cdt\u003e\u003cspan class=\"term\"\u003emessages\u003c/span\u003e\u003c/dt\u003e\n\u003cdd\u003e\n\u003cp\u003eBoolean option to enable sending the messages that are written by \u003ccode class=\"function\"\u003epg_logical_emit_message\u003c/code\u003e.\u003c/p\u003e\n\u003c/dd\u003e\n\u003cdt\u003e\u003cspan class=\"term\"\u003estreaming\u003c/span\u003e\u003c/dt\u003e\n\u003cdd\u003e\n\u003cp\u003eOption to enable streaming of in-progress transactions. Valid values are \u003ccode class=\"literal\"\u003eoff\u003c/code\u003e (the default), \u003ccode class=\"literal\"\u003eon\u003c/code\u003e and \u003ccode class=\"literal\"\u003eparallel\u003c/code\u003e. The setting \u003ccode class=\"literal\"\u003eparallel\u003c/code\u003e enables sending extra information with some messages to be used for parallelization. Minimum protocol version 2 is required to turn it \u003ccode class=\"literal\"\u003eon\u003c/code\u003e. Minimum protocol version 4 is required for the \u003ccode class=\"literal\"\u003eparallel\u003c/code\u003e value.\u003c/p\u003e\n\u003c/dd\u003e\n\u003cdt\u003e\u003cspan class=\"term\"\u003etwo_phase\u003c/span\u003e\u003c/dt\u003e\n\u003cdd\u003e\n\u003cp\u003eBoolean option to enable two-phase transactions. Minimum protocol version 3 is required to turn it on.\u003c/p\u003e\n\u003c/dd\u003e\n\u003cdt\u003e\u003cspan class=\"term\"\u003eorigin\u003c/span\u003e\u003c/dt\u003e\n\u003cdd\u003e\n\u003cp\u003eOption to send changes by their origin. Possible values are \u003ccode class=\"literal\"\u003enone\u003c/code\u003e to only send the changes that have no origin associated, or \u003ccode class=\"literal\"\u003eany\u003c/code\u003e to send the changes regardless of their origin. This can be used to avoid loops (infinite replication of the same data) among replication nodes.\u003c/p\u003e\n\u003c/dd\u003e\n\u003c/dl\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\u003cdiv class=\"sect2\" id=\"PROTOCOL-LOGICAL-MESSAGES\"\u003e\n\u003cdiv class=\"titlepage\"\u003e\n\u003cdiv\u003e\n\u003cdiv\u003e\n\u003ch3 class=\"title\"\u003e54.5.2. Logical Replication Protocol Messages \u003c/h3\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\u003cp\u003eThe individual protocol messages are discussed in the following subsections. Individual messages are described in \u003ca class=\"xref\" href=\"/docs/18/protocol-logicalrep-message-formats.html\" title=\"54.9. Logical Replication Message Formats\"\u003eSection 54.9\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003eAll 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.\u003c/p\u003e\n\u003cp\u003eSince the streaming replication protocol supplies a message length there is no need for top-level protocol messages to embed a length in their header.\u003c/p\u003e\n\u003c/div\u003e\n\u003cdiv class=\"sect2\" id=\"PROTOCOL-LOGICAL-MESSAGES-FLOW\"\u003e\n\u003cdiv class=\"titlepage\"\u003e\n\u003cdiv\u003e\n\u003cdiv\u003e\n\u003ch3 class=\"title\"\u003e54.5.3. Logical Replication Protocol Message Flow \u003c/h3\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\u003cp\u003eWith the exception of the \u003ccode class=\"literal\"\u003eSTART_REPLICATION\u003c/code\u003e command and the replay progress messages, all information flows only from the backend to the frontend.\u003c/p\u003e\n\u003cp\u003eThe 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.\u003c/p\u003e\n\u003cp\u003eEvery 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.\u003c/p\u003e\n\u003cp\u003eEvery 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.)\u003c/p\u003e\n\u003cp\u003eRelation 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.\u003c/p\u003e\n\u003c/div\u003e\n\u003c/div\u003e","manual_path":"/docs/18/protocol-logical-replication.html","related":[{"label":"Logical decoding output interface","url":"/docs/18/logicaldecoding-output-plugin.html"},{"label":"Existing extension catalogue identity","url":"/e/pgoutput/"},{"label":"Logical Begin message","url":"/wiki/protocol/logical-begin/?v=18"},{"label":"Logical Relation message","url":"/wiki/protocol/logical-relation/?v=18"},{"label":"Logical tuple representation","url":"/wiki/protocol/logical-tupledata/?v=18"},{"label":"Logical Stream Start message","url":"/wiki/protocol/logical-stream-start/?v=18"},{"label":"Logical Prepare message","url":"/wiki/protocol/logical-prepare/?v=18"}],"release":{"channel":"stable","label":"18.6","major":"18","ref":"PostgreSQL 18.6 source archive","revision":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","source_snapshot_utc":"","source_url":"https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2"},"runtime_verified":false,"sections":[{"paragraphs":["The matrix records callbacks actually registered in this source build. Registration identifies an implemented interface hook; options, query shape, privileges and provider rules determine whether an operation is allowed.","The complete same-version manual below retains configuration, constraints and examples. No runtime capability test is claimed."],"title":"Interface and capability boundaries"},{"paragraphs":["Callback presence and protocol versions are separate from client negotiation and enabled plugin options. Streaming and two-phase processing require the matching protocol and configuration.","test_decoding is an example/test output format; pgoutput implements the logical-replication protocol. Their output contracts are not interchangeable."],"title":"Output and protocol boundaries"},{"code":"{\n\tcb-\u003estartup_cb = pgoutput_startup;\n\tcb-\u003ebegin_cb = pgoutput_begin_txn;\n\tcb-\u003echange_cb = pgoutput_change;\n\tcb-\u003etruncate_cb = pgoutput_truncate;\n\tcb-\u003emessage_cb = pgoutput_message;\n\tcb-\u003ecommit_cb = pgoutput_commit_txn;\n\n\tcb-\u003ebegin_prepare_cb = pgoutput_begin_prepare_txn;\n\tcb-\u003eprepare_cb = pgoutput_prepare_txn;\n\tcb-\u003ecommit_prepared_cb = pgoutput_commit_prepared_txn;\n\tcb-\u003erollback_prepared_cb = pgoutput_rollback_prepared_txn;\n\tcb-\u003efilter_by_origin_cb = pgoutput_origin_filter;\n\tcb-\u003eshutdown_cb = pgoutput_shutdown;\n\n\t/* transaction streaming */\n\tcb-\u003estream_start_cb = pgoutput_stream_start;\n\tcb-\u003estream_stop_cb = pgoutput_stream_stop;\n\tcb-\u003estream_abort_cb = pgoutput_stream_abort;\n\tcb-\u003estream_commit_cb = pgoutput_stream_commit;\n\tcb-\u003estream_change_cb = pgoutput_change;\n\tcb-\u003estream_message_cb = pgoutput_message;\n\tcb-\u003estream_truncate_cb = pgoutput_truncate;\n\t/* transaction streaming - two-phase commit */\n\tcb-\u003estream_prepare_cb = pgoutput_stream_prepare_txn;\n}","title":"Registered implementation in core source"}],"sources":[{"label":"PostgreSQL 18 English manual","path":"protocol-logical-replication.html","sha256":"db5675868e641807e48ae6e19f51ed2a9bc9a29bd1b7a365c16eb3cae022a18e","url":"/docs/18/protocol-logical-replication.html"},{"archive_sha256":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","label":"src/backend/replication/pgoutput/pgoutput.c:262","line":262,"path":"src/backend/replication/pgoutput/pgoutput.c","sha256":"0a16f2abc3218286200f1a0a9c1d67fb7115ec0145b5edd7e4bd66ecb4d07566","url":"https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2"},{"label":"PostgreSQL 18 English manual","path":"logicaldecoding-output-plugin.html","sha256":"e5b3d13adfcc9e33f24524cb09d93eb91a1292fdb3124234002ccccf93f45738","url":"/docs/18/logicaldecoding-output-plugin.html"},{"archive_sha256":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","label":"Logical replication protocol constants","path":"src/include/replication/logicalproto.h","sha256":"1c6101fa446aabe8d78a722fe62c4fce647f5b492ab4d7b460907ce73e035180","url":"https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2"}],"tables":[{"columns":[{"key":"feature","label":"Interface operation"},{"key":"state","label":"Source observation"},{"key":"callback","label":"Callback"},{"key":"implementation","label":"Implementation"}],"key":"callbacks","rows":[{"callback":"begin_cb","feature":"Begin transaction","implementation":"pgoutput_begin_txn","state":"Handler registered; conditions apply"},{"callback":"change_cb","feature":"Row changes","implementation":"pgoutput_change","state":"Handler registered; conditions apply"},{"callback":"commit_cb","feature":"Commit","implementation":"pgoutput_commit_txn","state":"Handler registered; conditions apply"},{"callback":"truncate_cb","feature":"TRUNCATE","implementation":"pgoutput_truncate","state":"Handler registered; conditions apply"},{"callback":"message_cb","feature":"Logical messages","implementation":"pgoutput_message","state":"Handler registered; conditions apply"},{"callback":"stream_start_cb","feature":"Start streamed transaction","implementation":"pgoutput_stream_start","state":"Handler registered; conditions apply"},{"callback":"stream_change_cb","feature":"Stream row changes","implementation":"pgoutput_change","state":"Handler registered; conditions apply"},{"callback":"prepare_cb","feature":"Prepare transaction","implementation":"pgoutput_prepare_txn","state":"Handler registered; conditions apply"},{"callback":"commit_prepared_cb","feature":"Commit prepared","implementation":"pgoutput_commit_prepared_txn","state":"Handler registered; conditions apply"},{"callback":"rollback_prepared_cb","feature":"Rollback prepared","implementation":"pgoutput_rollback_prepared_txn","state":"Handler registered; conditions apply"}],"title":"Registered interface handlers"},{"columns":[{"key":"name","label":"Option"},{"key":"definition","label":"Same-version definition"}],"key":"options","rows":[{"definition":"Protocol version. Currently versions 1 , 2 , 3 , and 4 are supported. A valid version is required. Version 2 is supported only for server version 14 and above, and it allows streaming of large in-progress transactions. Version 3 is supported only for server version 15 and above, and it allows streaming of two-phase commits. Version 4 is supported only for server version 16 and above, and it allows streams of large in-progress transactions to be applied in parallel.","name":"proto_version"},{"definition":"Comma-separated list of publication names for which to subscribe (receive changes). The individual publication names are treated as standard objects names and can be quoted the same as needed. At least one publication name is required.","name":"publication_names"},{"definition":"Boolean option to use binary transfer mode. Binary mode is faster than the text mode but slightly less robust.","name":"binary"},{"definition":"Boolean option to enable sending the messages that are written by pg_logical_emit_message .","name":"messages"},{"definition":"Option to enable streaming of in-progress transactions. Valid values are off (the default), on and parallel . The setting parallel enables sending extra information with some messages to be used for parallelization. Minimum protocol version 2 is required to turn it on . Minimum protocol version 4 is required for the parallel value.","name":"streaming"},{"definition":"Boolean option to enable two-phase transactions. Minimum protocol version 3 is required to turn it on.","name":"two_phase"},{"definition":"Option to send changes by their origin. Possible values are none to only send the changes that have no origin associated, or any to send the changes regardless of their origin. This can be used to avoid loops (infinite replication of the same data) among replication nodes.","name":"origin"}],"title":"Documented options"},{"caption":"Extracted from the option parser; names alone do not describe defaults, accepted values or protocol requirements.","columns":[{"key":"name","label":"Source option name"}],"key":"source-options","rows":[{"name":"binary"},{"name":"messages"},{"name":"origin"},{"name":"proto_version"},{"name":"publication_names"},{"name":"streaming"},{"name":"two_phase"}],"title":"Option names recognized by this plugin build"}]},"ManualEvidence":{"manual_path":"/docs/18/protocol-logical-replication.html","release":{"channel":"stable","label":"18.6","major":"18","ref":"PostgreSQL 18.6 source archive","revision":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","source_snapshot_utc":"","source_url":"https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2"},"sources":[{"label":"PostgreSQL 18 English manual","path":"protocol-logical-replication.html","sha256":"db5675868e641807e48ae6e19f51ed2a9bc9a29bd1b7a365c16eb3cae022a18e","url":"/docs/18/protocol-logical-replication.html"},{"archive_sha256":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","label":"src/backend/replication/pgoutput/pgoutput.c:262","line":262,"path":"src/backend/replication/pgoutput/pgoutput.c","sha256":"0a16f2abc3218286200f1a0a9c1d67fb7115ec0145b5edd7e4bd66ecb4d07566","url":"https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2"},{"label":"PostgreSQL 18 English manual","path":"logicaldecoding-output-plugin.html","sha256":"e5b3d13adfcc9e33f24524cb09d93eb91a1292fdb3124234002ccccf93f45738","url":"/docs/18/logicaldecoding-output-plugin.html"},{"archive_sha256":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","label":"Logical replication protocol constants","path":"src/include/replication/logicalproto.h","sha256":"1c6101fa446aabe8d78a722fe62c4fce647f5b492ab4d7b460907ce73e035180","url":"https://ftp.postgresql.org/pub/source/v18.6/postgresql-18.6.tar.bz2"}]},"MeasuredEvidence":{"runtime_verified":false}},"Text":{"Collection":"decode","Key":"pgoutput","SourceDatabase":"center","Version":"18","Locale":"en","Title":"pgoutput","Summary":"The built-in output plugin used by PostgreSQL logical replication.","BodyHTML":"\u003cdiv id=\"PROTOCOL-LOGICAL-REPLICATION\"\u003e\n\u003cdiv\u003e\n\u003cdiv\u003e\n\u003cdiv\u003e\n\u003ch2\u003e54.5. Logical Streaming Replication Protocol \u003c/h2\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\n\u003cp\u003eThis section describes the logical replication protocol, which is the message flow started by the \u003ccode\u003eSTART_REPLICATION\u003c/code\u003e \u003ccode\u003eSLOT\u003c/code\u003e \u003cem\u003e\u003ccode\u003eslot_name\u003c/code\u003e\u003c/em\u003e \u003ccode\u003eLOGICAL\u003c/code\u003e replication command.\u003c/p\u003e\n\u003cp\u003eThe logical streaming replication protocol builds on the primitives of the physical streaming replication protocol.\u003c/p\u003e\n\u003cp\u003e\u003cspan\u003ePostgreSQL\u003c/span\u003e logical decoding supports output plugins. \u003ccode\u003epgoutput\u003c/code\u003e is the standard one used for the built-in logical replication.\u003c/p\u003e\n\u003cdiv id=\"PROTOCOL-LOGICAL-REPLICATION-PARAMS\"\u003e\n\u003cdiv\u003e\n\u003cdiv\u003e\n\u003cdiv\u003e\n\u003ch3\u003e54.5.1. Logical Streaming Replication Parameters \u003c/h3\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\u003cp\u003eUsing the \u003ccode\u003eSTART_REPLICATION\u003c/code\u003e command, \u003ccode\u003epgoutput\u003c/code\u003e accepts the following options:\u003c/p\u003e\n\u003cdiv\u003e\n\u003cdl\u003e\n\u003cdt\u003e\u003cspan\u003eproto_version\u003c/span\u003e\u003c/dt\u003e\n\u003cdd\u003e\n\u003cp\u003eProtocol version. Currently versions \u003ccode\u003e1\u003c/code\u003e, \u003ccode\u003e2\u003c/code\u003e, \u003ccode\u003e3\u003c/code\u003e, and \u003ccode\u003e4\u003c/code\u003e are supported. A valid version is required.\u003c/p\u003e\n\u003cp\u003eVersion \u003ccode\u003e2\u003c/code\u003e is supported only for server version 14 and above, and it allows streaming of large in-progress transactions.\u003c/p\u003e\n\u003cp\u003eVersion \u003ccode\u003e3\u003c/code\u003e is supported only for server version 15 and above, and it allows streaming of two-phase commits.\u003c/p\u003e\n\u003cp\u003eVersion \u003ccode\u003e4\u003c/code\u003e is supported only for server version 16 and above, and it allows streams of large in-progress transactions to be applied in parallel.\u003c/p\u003e\n\u003c/dd\u003e\n\u003cdt\u003e\u003cspan\u003epublication_names\u003c/span\u003e\u003c/dt\u003e\n\u003cdd\u003e\n\u003cp\u003eComma-separated list of publication names for which to subscribe (receive changes). The individual publication names are treated as standard objects names and can be quoted the same as needed. At least one publication name is required.\u003c/p\u003e\n\u003c/dd\u003e\n\u003cdt\u003e\u003cspan\u003ebinary\u003c/span\u003e\u003c/dt\u003e\n\u003cdd\u003e\n\u003cp\u003eBoolean option to use binary transfer mode. Binary mode is faster than the text mode but slightly less robust.\u003c/p\u003e\n\u003c/dd\u003e\n\u003cdt\u003e\u003cspan\u003emessages\u003c/span\u003e\u003c/dt\u003e\n\u003cdd\u003e\n\u003cp\u003eBoolean option to enable sending the messages that are written by \u003ccode\u003epg_logical_emit_message\u003c/code\u003e.\u003c/p\u003e\n\u003c/dd\u003e\n\u003cdt\u003e\u003cspan\u003estreaming\u003c/span\u003e\u003c/dt\u003e\n\u003cdd\u003e\n\u003cp\u003eOption to enable streaming of in-progress transactions. Valid values are \u003ccode\u003eoff\u003c/code\u003e (the default), \u003ccode\u003eon\u003c/code\u003e and \u003ccode\u003eparallel\u003c/code\u003e. The setting \u003ccode\u003eparallel\u003c/code\u003e enables sending extra information with some messages to be used for parallelization. Minimum protocol version 2 is required to turn it \u003ccode\u003eon\u003c/code\u003e. Minimum protocol version 4 is required for the \u003ccode\u003eparallel\u003c/code\u003e value.\u003c/p\u003e\n\u003c/dd\u003e\n\u003cdt\u003e\u003cspan\u003etwo_phase\u003c/span\u003e\u003c/dt\u003e\n\u003cdd\u003e\n\u003cp\u003eBoolean option to enable two-phase transactions. Minimum protocol version 3 is required to turn it on.\u003c/p\u003e\n\u003c/dd\u003e\n\u003cdt\u003e\u003cspan\u003eorigin\u003c/span\u003e\u003c/dt\u003e\n\u003cdd\u003e\n\u003cp\u003eOption to send changes by their origin. Possible values are \u003ccode\u003enone\u003c/code\u003e to only send the changes that have no origin associated, or \u003ccode\u003eany\u003c/code\u003e to send the changes regardless of their origin. This can be used to avoid loops (infinite replication of the same data) among replication nodes.\u003c/p\u003e\n\u003c/dd\u003e\n\u003c/dl\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\u003cdiv id=\"PROTOCOL-LOGICAL-MESSAGES\"\u003e\n\u003cdiv\u003e\n\u003cdiv\u003e\n\u003cdiv\u003e\n\u003ch3\u003e54.5.2. Logical Replication Protocol Messages \u003c/h3\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\u003cp\u003eThe individual protocol messages are discussed in the following subsections. Individual messages are described in \u003ca href=\"/docs/18/protocol-logicalrep-message-formats.html\" rel=\"nofollow\"\u003eSection 54.9\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003eAll 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.\u003c/p\u003e\n\u003cp\u003eSince the streaming replication protocol supplies a message length there is no need for top-level protocol messages to embed a length in their header.\u003c/p\u003e\n\u003c/div\u003e\n\u003cdiv id=\"PROTOCOL-LOGICAL-MESSAGES-FLOW\"\u003e\n\u003cdiv\u003e\n\u003cdiv\u003e\n\u003cdiv\u003e\n\u003ch3\u003e54.5.3. Logical Replication Protocol Message Flow \u003c/h3\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\u003cp\u003eWith the exception of the \u003ccode\u003eSTART_REPLICATION\u003c/code\u003e command and the replay progress messages, all information flows only from the backend to the frontend.\u003c/p\u003e\n\u003cp\u003eThe 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.\u003c/p\u003e\n\u003cp\u003eEvery 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\u0026#39;s downstream\u0026#39;s responsibility to handle this as needed (if needed). The Origin message is always sent before any DML messages in the transaction.\u003c/p\u003e\n\u003cp\u003eEvery DML message contains a relation OID, identifying the publisher\u0026#39;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\u0026#39;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.)\u003c/p\u003e\n\u003cp\u003eRelation 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.\u003c/p\u003e\n\u003c/div\u003e\n\u003c/div\u003e","SourceRevision":"555610c24d53e4316da5b7d3fc25c279d96856d5e0e23ee308c328c5fa881d9f","ContentHash":"9842a272eef6921759df50137d7d8408f4a121e7d3cfcf34bf9318bc6fbe2794","Payload":{"description":["The built-in output plugin used by PostgreSQL logical replication."],"manual_html":"\u003cdiv class=\"sect1\" id=\"PROTOCOL-LOGICAL-REPLICATION\"\u003e\n\u003cdiv class=\"titlepage\"\u003e\n\u003cdiv\u003e\n\u003cdiv\u003e\n\u003ch2 class=\"title\"\u003e54.5. Logical Streaming Replication Protocol \u003c/h2\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\n\u003cp\u003eThis section describes the logical replication protocol, which is the message flow started by the \u003ccode class=\"literal\"\u003eSTART_REPLICATION\u003c/code\u003e \u003ccode class=\"literal\"\u003eSLOT\u003c/code\u003e \u003cem class=\"replaceable\"\u003e\u003ccode\u003eslot_name\u003c/code\u003e\u003c/em\u003e \u003ccode class=\"literal\"\u003eLOGICAL\u003c/code\u003e replication command.\u003c/p\u003e\n\u003cp\u003eThe logical streaming replication protocol builds on the primitives of the physical streaming replication protocol.\u003c/p\u003e\n\u003cp\u003e\u003cspan class=\"productname\"\u003ePostgreSQL\u003c/span\u003e logical decoding supports output plugins. \u003ccode class=\"literal\"\u003epgoutput\u003c/code\u003e is the standard one used for the built-in logical replication.\u003c/p\u003e\n\u003cdiv class=\"sect2\" id=\"PROTOCOL-LOGICAL-REPLICATION-PARAMS\"\u003e\n\u003cdiv class=\"titlepage\"\u003e\n\u003cdiv\u003e\n\u003cdiv\u003e\n\u003ch3 class=\"title\"\u003e54.5.1. Logical Streaming Replication Parameters \u003c/h3\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\u003cp\u003eUsing the \u003ccode class=\"literal\"\u003eSTART_REPLICATION\u003c/code\u003e command, \u003ccode class=\"literal\"\u003epgoutput\u003c/code\u003e accepts the following options:\u003c/p\u003e\n\u003cdiv class=\"variablelist\"\u003e\n\u003cdl class=\"variablelist\"\u003e\n\u003cdt\u003e\u003cspan class=\"term\"\u003eproto_version\u003c/span\u003e\u003c/dt\u003e\n\u003cdd\u003e\n\u003cp\u003eProtocol version. Currently versions \u003ccode class=\"literal\"\u003e1\u003c/code\u003e, \u003ccode class=\"literal\"\u003e2\u003c/code\u003e, \u003ccode class=\"literal\"\u003e3\u003c/code\u003e, and \u003ccode class=\"literal\"\u003e4\u003c/code\u003e are supported. A valid version is required.\u003c/p\u003e\n\u003cp\u003eVersion \u003ccode class=\"literal\"\u003e2\u003c/code\u003e is supported only for server version 14 and above, and it allows streaming of large in-progress transactions.\u003c/p\u003e\n\u003cp\u003eVersion \u003ccode class=\"literal\"\u003e3\u003c/code\u003e is supported only for server version 15 and above, and it allows streaming of two-phase commits.\u003c/p\u003e\n\u003cp\u003eVersion \u003ccode class=\"literal\"\u003e4\u003c/code\u003e is supported only for server version 16 and above, and it allows streams of large in-progress transactions to be applied in parallel.\u003c/p\u003e\n\u003c/dd\u003e\n\u003cdt\u003e\u003cspan class=\"term\"\u003epublication_names\u003c/span\u003e\u003c/dt\u003e\n\u003cdd\u003e\n\u003cp\u003eComma-separated list of publication names for which to subscribe (receive changes). The individual publication names are treated as standard objects names and can be quoted the same as needed. At least one publication name is required.\u003c/p\u003e\n\u003c/dd\u003e\n\u003cdt\u003e\u003cspan class=\"term\"\u003ebinary\u003c/span\u003e\u003c/dt\u003e\n\u003cdd\u003e\n\u003cp\u003eBoolean option to use binary transfer mode. Binary mode is faster than the text mode but slightly less robust.\u003c/p\u003e\n\u003c/dd\u003e\n\u003cdt\u003e\u003cspan class=\"term\"\u003emessages\u003c/span\u003e\u003c/dt\u003e\n\u003cdd\u003e\n\u003cp\u003eBoolean option to enable sending the messages that are written by \u003ccode class=\"function\"\u003epg_logical_emit_message\u003c/code\u003e.\u003c/p\u003e\n\u003c/dd\u003e\n\u003cdt\u003e\u003cspan class=\"term\"\u003estreaming\u003c/span\u003e\u003c/dt\u003e\n\u003cdd\u003e\n\u003cp\u003eOption to enable streaming of in-progress transactions. Valid values are \u003ccode class=\"literal\"\u003eoff\u003c/code\u003e (the default), \u003ccode class=\"literal\"\u003eon\u003c/code\u003e and \u003ccode class=\"literal\"\u003eparallel\u003c/code\u003e. The setting \u003ccode class=\"literal\"\u003eparallel\u003c/code\u003e enables sending extra information with some messages to be used for parallelization. Minimum protocol version 2 is required to turn it \u003ccode class=\"literal\"\u003eon\u003c/code\u003e. Minimum protocol version 4 is required for the \u003ccode class=\"literal\"\u003eparallel\u003c/code\u003e value.\u003c/p\u003e\n\u003c/dd\u003e\n\u003cdt\u003e\u003cspan class=\"term\"\u003etwo_phase\u003c/span\u003e\u003c/dt\u003e\n\u003cdd\u003e\n\u003cp\u003eBoolean option to enable two-phase transactions. Minimum protocol version 3 is required to turn it on.\u003c/p\u003e\n\u003c/dd\u003e\n\u003cdt\u003e\u003cspan class=\"term\"\u003eorigin\u003c/span\u003e\u003c/dt\u003e\n\u003cdd\u003e\n\u003cp\u003eOption to send changes by their origin. Possible values are \u003ccode class=\"literal\"\u003enone\u003c/code\u003e to only send the changes that have no origin associated, or \u003ccode class=\"literal\"\u003eany\u003c/code\u003e to send the changes regardless of their origin. This can be used to avoid loops (infinite replication of the same data) among replication nodes.\u003c/p\u003e\n\u003c/dd\u003e\n\u003c/dl\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\u003cdiv class=\"sect2\" id=\"PROTOCOL-LOGICAL-MESSAGES\"\u003e\n\u003cdiv class=\"titlepage\"\u003e\n\u003cdiv\u003e\n\u003cdiv\u003e\n\u003ch3 class=\"title\"\u003e54.5.2. Logical Replication Protocol Messages \u003c/h3\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\u003cp\u003eThe individual protocol messages are discussed in the following subsections. Individual messages are described in \u003ca class=\"xref\" href=\"/docs/18/protocol-logicalrep-message-formats.html\" title=\"54.9. Logical Replication Message Formats\"\u003eSection 54.9\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003eAll 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.\u003c/p\u003e\n\u003cp\u003eSince the streaming replication protocol supplies a message length there is no need for top-level protocol messages to embed a length in their header.\u003c/p\u003e\n\u003c/div\u003e\n\u003cdiv class=\"sect2\" id=\"PROTOCOL-LOGICAL-MESSAGES-FLOW\"\u003e\n\u003cdiv class=\"titlepage\"\u003e\n\u003cdiv\u003e\n\u003cdiv\u003e\n\u003ch3 class=\"title\"\u003e54.5.3. Logical Replication Protocol Message Flow \u003c/h3\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\u003c/div\u003e\n\u003cp\u003eWith the exception of the \u003ccode class=\"literal\"\u003eSTART_REPLICATION\u003c/code\u003e command and the replay progress messages, all information flows only from the backend to the frontend.\u003c/p\u003e\n\u003cp\u003eThe 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.\u003c/p\u003e\n\u003cp\u003eEvery 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.\u003c/p\u003e\n\u003cp\u003eEvery 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.)\u003c/p\u003e\n\u003cp\u003eRelation 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.\u003c/p\u003e\n\u003c/div\u003e\n\u003c/div\u003e","related":[{"label":"Logical decoding output interface","url":"/docs/18/logicaldecoding-output-plugin.html"},{"label":"Existing extension catalogue identity","url":"/e/pgoutput/"},{"label":"Logical Begin message","url":"/wiki/protocol/logical-begin/?v=18"},{"label":"Logical Relation message","url":"/wiki/protocol/logical-relation/?v=18"},{"label":"Logical tuple representation","url":"/wiki/protocol/logical-tupledata/?v=18"},{"label":"Logical Stream Start message","url":"/wiki/protocol/logical-stream-start/?v=18"},{"label":"Logical Prepare message","url":"/wiki/protocol/logical-prepare/?v=18"}],"sections":[{"paragraphs":["The matrix records callbacks actually registered in this source build. Registration identifies an implemented interface hook; options, query shape, privileges and provider rules determine whether an operation is allowed.","The complete same-version manual below retains configuration, constraints and examples. No runtime capability test is claimed."],"title":"Interface and capability boundaries"},{"paragraphs":["Callback presence and protocol versions are separate from client negotiation and enabled plugin options. Streaming and two-phase processing require the matching protocol and configuration.","test_decoding is an example/test output format; pgoutput implements the logical-replication protocol. Their output contracts are not interchangeable."],"title":"Output and protocol boundaries"},{"code":"{\n\tcb-\u003estartup_cb = pgoutput_startup;\n\tcb-\u003ebegin_cb = pgoutput_begin_txn;\n\tcb-\u003echange_cb = pgoutput_change;\n\tcb-\u003etruncate_cb = pgoutput_truncate;\n\tcb-\u003emessage_cb = pgoutput_message;\n\tcb-\u003ecommit_cb = pgoutput_commit_txn;\n\n\tcb-\u003ebegin_prepare_cb = pgoutput_begin_prepare_txn;\n\tcb-\u003eprepare_cb = pgoutput_prepare_txn;\n\tcb-\u003ecommit_prepared_cb = pgoutput_commit_prepared_txn;\n\tcb-\u003erollback_prepared_cb = pgoutput_rollback_prepared_txn;\n\tcb-\u003efilter_by_origin_cb = pgoutput_origin_filter;\n\tcb-\u003eshutdown_cb = pgoutput_shutdown;\n\n\t/* transaction streaming */\n\tcb-\u003estream_start_cb = pgoutput_stream_start;\n\tcb-\u003estream_stop_cb = pgoutput_stream_stop;\n\tcb-\u003estream_abort_cb = pgoutput_stream_abort;\n\tcb-\u003estream_commit_cb = pgoutput_stream_commit;\n\tcb-\u003estream_change_cb = pgoutput_change;\n\tcb-\u003estream_message_cb = pgoutput_message;\n\tcb-\u003estream_truncate_cb = pgoutput_truncate;\n\t/* transaction streaming - two-phase commit */\n\tcb-\u003estream_prepare_cb = pgoutput_stream_prepare_txn;\n}","title":"Registered implementation in core source"}],"tables":[{"columns":[{"key":"feature","label":"Interface operation"},{"key":"state","label":"Source observation"},{"key":"callback","label":"Callback"},{"key":"implementation","label":"Implementation"}],"key":"callbacks","rows":[{"callback":"begin_cb","feature":"Begin transaction","implementation":"pgoutput_begin_txn","state":"Handler registered; conditions apply"},{"callback":"change_cb","feature":"Row changes","implementation":"pgoutput_change","state":"Handler registered; conditions apply"},{"callback":"commit_cb","feature":"Commit","implementation":"pgoutput_commit_txn","state":"Handler registered; conditions apply"},{"callback":"truncate_cb","feature":"TRUNCATE","implementation":"pgoutput_truncate","state":"Handler registered; conditions apply"},{"callback":"message_cb","feature":"Logical messages","implementation":"pgoutput_message","state":"Handler registered; conditions apply"},{"callback":"stream_start_cb","feature":"Start streamed transaction","implementation":"pgoutput_stream_start","state":"Handler registered; conditions apply"},{"callback":"stream_change_cb","feature":"Stream row changes","implementation":"pgoutput_change","state":"Handler registered; conditions apply"},{"callback":"prepare_cb","feature":"Prepare transaction","implementation":"pgoutput_prepare_txn","state":"Handler registered; conditions apply"},{"callback":"commit_prepared_cb","feature":"Commit prepared","implementation":"pgoutput_commit_prepared_txn","state":"Handler registered; conditions apply"},{"callback":"rollback_prepared_cb","feature":"Rollback prepared","implementation":"pgoutput_rollback_prepared_txn","state":"Handler registered; conditions apply"}],"title":"Registered interface handlers"},{"columns":[{"key":"name","label":"Option"},{"key":"definition","label":"Same-version definition"}],"key":"options","rows":[{"definition":"Protocol version. Currently versions 1 , 2 , 3 , and 4 are supported. A valid version is required. Version 2 is supported only for server version 14 and above, and it allows streaming of large in-progress transactions. Version 3 is supported only for server version 15 and above, and it allows streaming of two-phase commits. Version 4 is supported only for server version 16 and above, and it allows streams of large in-progress transactions to be applied in parallel.","name":"proto_version"},{"definition":"Comma-separated list of publication names for which to subscribe (receive changes). The individual publication names are treated as standard objects names and can be quoted the same as needed. At least one publication name is required.","name":"publication_names"},{"definition":"Boolean option to use binary transfer mode. Binary mode is faster than the text mode but slightly less robust.","name":"binary"},{"definition":"Boolean option to enable sending the messages that are written by pg_logical_emit_message .","name":"messages"},{"definition":"Option to enable streaming of in-progress transactions. Valid values are off (the default), on and parallel . The setting parallel enables sending extra information with some messages to be used for parallelization. Minimum protocol version 2 is required to turn it on . Minimum protocol version 4 is required for the parallel value.","name":"streaming"},{"definition":"Boolean option to enable two-phase transactions. Minimum protocol version 3 is required to turn it on.","name":"two_phase"},{"definition":"Option to send changes by their origin. Possible values are none to only send the changes that have no origin associated, or any to send the changes regardless of their origin. This can be used to avoid loops (infinite replication of the same data) among replication nodes.","name":"origin"}],"title":"Documented options"},{"caption":"Extracted from the option parser; names alone do not describe defaults, accepted values or protocol requirements.","columns":[{"key":"name","label":"Source option name"}],"key":"source-options","rows":[{"name":"binary"},{"name":"messages"},{"name":"origin"},{"name":"proto_version"},{"name":"publication_names"},{"name":"streaming"},{"name":"two_phase"}],"title":"Option names recognized by this plugin build"}]}},"RequestedLocale":"zh-Hans","Fallback":true,"Versions":["10","11","12","13","14","15","16","17","18","19","20"],"Locales":["en"],"Signatures":null,"Spellings":null,"SQLState":null,"Evidence":null}