Hi,

On 7/21/19 9:48 PM, Michael Paquier wrote:
Since pg_receivewal does not apply WAL, you should not allow it to
become a synchronous standby when synchronous_commit = remote_apply.
If it does, it will appear to be a standby which never catches up,
which may cause commits to block.  To avoid this, you should either
configure an appropriate value for synchronous_standby_names, or
specify an application_name for pg_receivewal that does not match it,
or change the value of synchronous_commit to something other than
remote_apply.

I think that'd be a lot more useful than enumerating the total-failure
scenarios.

+1.  Thanks for the suggestions!  Your wording looks good to me.

+1

Here is the patch for it, with Robert as the author.

Best regards,
 Jesper

>From a6512e79e9fd054b188489757ee622dbf98ddf2b Mon Sep 17 00:00:00 2001
From: jesperpedersen <jesper.peder...@redhat.com>
Date: Mon, 22 Jul 2019 13:19:56 -0400
Subject: [PATCH] Highlight that pg_receivewal doesn't apply WAL, and as such
 synchronous-commit needs to be remote_write or lower.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Author: Robert Haas
Review-by: Michael Paquier, Álvaro Herrera, Laurenz Albe and Jesper Pedersen
---
 doc/src/sgml/ref/pg_receivewal.sgml | 21 ++++++++++-----------
 1 file changed, 10 insertions(+), 11 deletions(-)

diff --git a/doc/src/sgml/ref/pg_receivewal.sgml b/doc/src/sgml/ref/pg_receivewal.sgml
index e96d753955..beab6f0391 100644
--- a/doc/src/sgml/ref/pg_receivewal.sgml
+++ b/doc/src/sgml/ref/pg_receivewal.sgml
@@ -52,7 +52,16 @@ PostgreSQL documentation
    Unlike the WAL receiver of a PostgreSQL standby server, <application>pg_receivewal</application>
    by default flushes WAL data only when a WAL file is closed.
    The option <option>--synchronous</option> must be specified to flush WAL data
-   in real time.
+   in real time. Since <application>pg_receivewal</application> does not apply WAL,
+   you should not allow it to become a synchronous standby when
+   <xref linkend="guc-synchronous-commit"/> equals <literal>remote_apply</literal>.
+   If it does, it will appear to be a standby which never catches up,
+   which may cause commits to block.  To avoid this, you should either
+   configure an appropriate value for <xref linkend="guc-synchronous-standby-names"/>, or
+   specify an <varname>application_name</varname> for
+   <application>pg_receivewal</application> that does not match it, or change the value of
+   <xref linkend="guc-synchronous-commit"/> to something other than
+   <literal>remote_apply</literal>.
   </para>
 
   <para>
@@ -207,16 +216,6 @@ PostgreSQL documentation
         server as a synchronous standby, to ensure that timely feedback is
         sent to the server.
        </para>
-
-       <para>
-        Note that while WAL will be flushed with this setting,
-        <application>pg_receivewal</application> never applies it,
-        so <xref linkend="guc-synchronous-commit"/> must not be set
-        to <literal>remote_apply</literal> or <literal>on</literal> if
-        <application>pg_receivewal</application> is a synchronous standby, be it a
-        member of a priority-based (<literal>FIRST</literal>) or a
-        quorum-based (<literal>ANY</literal>) synchronous replication setup.
-       </para>
       </listitem>
      </varlistentry>
 
-- 
2.21.0

Reply via email to