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
