From 7774783114e14d04c728bd0ad04a5286a4307bd2 Mon Sep 17 00:00:00 2001
From: Emre Hasegeli <emre@hasegeli.com>
Date: Mon, 20 Mar 2023 17:02:45 +0100
Subject: [PATCH v00 2/2] pgoutput: Document missing options

---
 doc/src/sgml/logical-replication.sgml |  3 +-
 doc/src/sgml/protocol.sgml            | 81 ++++++++++++++++++++++++++-
 2 files changed, 81 insertions(+), 3 deletions(-)

diff --git a/doc/src/sgml/logical-replication.sgml b/doc/src/sgml/logical-replication.sgml
index 1bb85e4ad9..e7fd1a38b2 100644
--- a/doc/src/sgml/logical-replication.sgml
+++ b/doc/src/sgml/logical-replication.sgml
@@ -1655,21 +1655,22 @@ CONTEXT:  processing remote data for replication origin "pg_16395" during "INSER
    transactional consistency is guaranteed for the publications within any
    single subscription.
   </para>
 
   <para>
    Logical replication is built with an architecture similar to physical
    streaming replication (see <xref linkend="streaming-replication"/>).  It is
    implemented by <literal>walsender</literal> and <literal>apply</literal>
    processes.  The walsender process starts logical decoding (described
    in <xref linkend="logicaldecoding"/>) of the WAL and loads the standard
-   logical decoding plugin (pgoutput).  The plugin transforms the changes read
+   logical decoding plugin (<literal>pgoutput</literal>).  The plugin
+   transforms the changes read
    from WAL to the logical replication protocol
    (see <xref linkend="protocol-logical-replication"/>) and filters the data
    according to the publication specification.  The data is then continuously
    transferred using the streaming replication protocol to the apply worker,
    which maps the data to local tables and applies the individual changes as
    they are received, in correct transactional order.
   </para>
 
   <para>
    The apply process on the subscriber database always runs with
diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
index af3f016f74..d4c500adcc 100644
--- a/doc/src/sgml/protocol.sgml
+++ b/doc/src/sgml/protocol.sgml
@@ -3075,26 +3075,32 @@ psql "dbname=postgres replication=database" -c "IDENTIFY_SYSTEM;"
   flow started by the <literal>START_REPLICATION</literal>
   <literal>SLOT</literal> <replaceable class="parameter">slot_name</replaceable>
   <literal>LOGICAL</literal> replication command.
  </para>
 
  <para>
   The logical streaming replication protocol builds on the primitives of
   the physical streaming replication protocol.
  </para>
 
+ <para>
+  <productname>PostgreSQL</productname> supports extensible logical decoding
+  plugins.  <literal>pgoutput</literal> is the standard one used for
+  the built-in logical replication.
+ </para>
+
  <sect2 id="protocol-logical-replication-params">
   <title>Logical Streaming Replication Parameters</title>
 
   <para>
-   The logical replication <literal>START_REPLICATION</literal> command
-   accepts following parameters:
+   The standard logical decoding plugin (<literal>pgoutput</literal>) accepts
+   following parameters with <literal>START_REPLICATION</literal> command:
 
    <variablelist>
     <varlistentry>
      <term>
       proto_version
      </term>
      <listitem>
       <para>
        Protocol version. Currently versions <literal>1</literal>, <literal>2</literal>,
        <literal>3</literal>, and <literal>4</literal> are supported.
@@ -3120,20 +3126,91 @@ psql "dbname=postgres replication=database" -c "IDENTIFY_SYSTEM;"
       publication_names
      </term>
      <listitem>
       <para>
        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.
       </para>
      </listitem>
     </varlistentry>
+
+<!-- Backpack through version 14. -->
+    <varlistentry>
+     <term>
+      binary
+     </term>
+     <listitem>
+      <para>
+       Boolean parameter to use the binary transfer mode.  This is faster
+       than the text mode, but slightly less robust.
+      </para>
+     </listitem>
+    </varlistentry>
+
+<!-- Backpack through version 14. -->
+    <varlistentry>
+     <term>
+      messages
+     </term>
+     <listitem>
+      <para>
+       Boolean parameter to enable sending the messages that are written
+       by <function>pg_logical_emit_message</function>.
+      </para>
+     </listitem>
+    </varlistentry>
+
+<!-- Backpack through version 14, but remove "parallel" part until version 16. -->
+    <varlistentry>
+     <term>
+      streaming
+     </term>
+     <listitem>
+      <para>
+       Boolean parameter to enable streaming of in-progress transactions.
+       It accepts an additional value "parallel" to enable sending extra
+       information with the "Stream Abort" messages to be used for
+       parallelisation.  Minimum protocol version 2 is required to turn it on.
+       Minimum protocol version 4 is required for the "parallel" option.
+      </para>
+     </listitem>
+    </varlistentry>
+
+<!-- Backpack through version 15. -->
+    <varlistentry>
+     <term>
+      two_phase
+     </term>
+     <listitem>
+      <para>
+       Boolean parameter to enable two-phase transactions.   Minimum protocol
+       version 3 is required to turn it on.
+      </para>
+     </listitem>
+    </varlistentry>
+
+<!-- Backpack through version 16. -->
+    <varlistentry>
+     <term>
+      origin
+     </term>
+     <listitem>
+      <para>
+       String parameter to send only changes by an origin.  It also gets
+       the option "none" to send the changes that have no origin associated,
+       and the option "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.
+      </para>
+     </listitem>
+    </varlistentry>
    </variablelist>
 
   </para>
  </sect2>
 
  <sect2 id="protocol-logical-messages">
   <title>Logical Replication Protocol Messages</title>
 
   <para>
    The individual protocol messages are discussed in the following
-- 
2.39.3 (Apple Git-145)