On Thu, Jul 18, 2019 at 08:40:36AM -0400, Jesper Pedersen wrote: > On 7/18/19 1:29 AM, Michael Paquier wrote: >> Or more simply like that? >> "Note that while WAL will be flushed with this setting, >> pg_receivewal never applies it, so synchronous_commit must not be set >> to remote_apply if pg_receivewal is a synchronous standby, be it a >> member of a priority-based (FIRST) or a quorum-based (ANY) synchronous >> replication setup." > > Yeah, better.
I was looking into committing that, and the part about synchronous_commit = on is not right. The location of the warning is also harder to catch for the reader, so instead let's move it to the top where we have an extra description for --synchronous. I am finishing with the attached that I would be fine to commit and back-patch as needed. Does that sound fine? -- Michael
diff --git a/doc/src/sgml/ref/pg_receivewal.sgml b/doc/src/sgml/ref/pg_receivewal.sgml
index 0506120c00..3670e9c6f9 100644
--- a/doc/src/sgml/ref/pg_receivewal.sgml
+++ b/doc/src/sgml/ref/pg_receivewal.sgml
@@ -52,7 +52,14 @@ 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. Note that while WAL will be flushed with this setting,
+ <application>pg_receivewal</application> never applies WAL, so
+ <xref linkend="guc-synchronous-commit"/> must not be set to
+ <literal>remote_apply</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
+ as set in <xref linkend="guc-synchronous-standby-names"/>.
</para>
<para>
signature.asc
Description: PGP signature
