On Wed, 2019-07-17 at 13:59 -0400, Jesper Pedersen wrote:
> + <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 the only synchronous standby.
> + Similarly, if <application>pg_receivewal</application> is part of a
> + priority-based synchronous replication setup (<literal>FIRST</literal>),
> + or a quorum-based setup (<literal>ANY</literal>) it won't count towards
> + the policy specified if <xref linkend="guc-synchronous-commit"/> is
> + set to <literal>remote_apply</literal> or <literal>on</literal>.
> + </para>
That's factually wrong. "on" (wait for WAL flush) works fine with
pg_receivewal, only "remote_apply" doesn't.
Ok, here's another attempt:
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> if <application>pg_receivewal</application>
is the only synchronous standby.
Similarly, it is no use adding <application>pg_receivewal</application> to a
priority-based (<literal>FIRST</literal>) or a quorum-based
(<literal>ANY</literal>) synchronous replication setup if
<xref linkend="guc-synchronous-commit"/> is set to <literal>remote_apply</literal>.
Yours,
Laurenz Albe