From: Jesper Pedersen <jesper.pedersen@redhat.com>
To: Michael Paquier <michael@paquier.xyz>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: pg_receivewal documentation
Date: Mon, 22 Jul 2019 13:25:41 -0400
Message-ID: <9fea76ce-6912-c262-6f64-2b7c4496be65@redhat.com> (raw)
In-Reply-To: <20190722014851.GC1757@paquier.xyz>
References: <20190710142421.GA28387@alvherre.pgsql>
<54779de5-f922-c0cf-629d-b582eded7265@redhat.com>
<20190716050555.GA1439@paquier.xyz>
<ebed4b9043b222d486ea3f0e44e7dcd242a80781.camel@cybertec.at>
<65c3ecdf-8995-34cb-83c4-50068877e632@redhat.com>
<20190717013835.GA2130@paquier.xyz>
<CA+TgmoY-8im5GHnSf1zih8t66DOcy7CO+i_p01LbP6ck+Unhpg@mail.gmail.com>
<20190722014851.GC1757@paquier.xyz>
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
Attachments:v9_pgreceivewal-doc.patch (text/x-patch, 2.6K) download
From a6512e79e9fd054b188489757ee622dbf98ddf2b Mon Sep 17 00:00:00 2001
From: jesperpedersen <jesper.pedersen@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.sgmlindex 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 instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: jesper.pedersen@redhat.com, michael@paquier.xyz, robertmhaas@gmail.com, laurenz.albe@cybertec.at, alvherre@2ndquadrant.com
Subject: Re: pg_receivewal documentation
In-Reply-To: <9fea76ce-6912-c262-6f64-2b7c4496be65@redhat.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox