From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com> |
Cc: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_receivewal documentation |
Date: | 2019-07-17 01:38:35 |
Message-ID: | 20190717013835.GA2130@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jul 16, 2019 at 01:03:12PM -0400, Jesper Pedersen wrote:
> Here is the patch for that.
+ <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> if <application>pg_receivewal</application>
+ is the only synchronous standby. Similarly, if
+ <application>pg_receivewal</application> is part of a quorum-based
+ set of synchronous standbys, it won't count towards the quorum if
+ <xref linkend="guc-synchronous-commit"/> is set to
+ <literal>remote_apply</literal>.
+ </para>
I think we should really document the caveat with priority-based sets
of standbys as much as quorum-based sets. For example if a user sets
synchronous_commit = remote_apply in postgresql.conf, and then sets
s_s_names to '2(pg_receivewal, my_connected_standby)' to get a
priority-based set, then you have the same problem, and pg_receivewal
is not the only synchronous standby in this configuration. The patch
does not cover that case properly.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Melanie Plageman | 2019-07-17 01:49:10 | Re: Extracting only the columns needed for a query |
Previous Message | David Rowley | 2019-07-17 01:20:18 | Re: Parallel Append subplan order instability on aye-aye |