From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
Cc: | jesper(dot)pedersen(at)redhat(dot)com, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_receivewal documentation |
Date: | 2019-07-18 05:29:09 |
Message-ID: | 20190718052909.GF1416@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jul 17, 2019 at 11:21:06PM +0200, Laurenz Albe wrote:
> 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>.
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."
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2019-07-18 05:38:34 | Re: Intermittent pg_ctl failures on Windows |
Previous Message | Amit Langote | 2019-07-18 05:24:29 | Re: partition routing layering in nodeModifyTable.c |