From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_receivewal documentation |
Date: | 2019-07-16 05:05:55 |
Message-ID: | 20190716050555.GA1439@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jul 10, 2019 at 11:26:04AM -0400, Jesper Pedersen wrote:
> On 7/10/19 10:24 AM, Alvaro Herrera wrote:
> > +1 to document this caveat.
>>
>> How about
>> 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.
>> ?
>>
>
> Sure.
This is not true in all cases as since 9.6 it is possible to specify
multiple synchronous standbys. So if for example pg_receivewal and
another synchronous standby are set in s_s_names and that the number
of a FIRST (priority-based) or ANY (quorum set) is two, then the same
issue exists, but this documentation is incorrect. I think that we
should have a more extensive wording here, like "if pg_receivewal is
part of a quorum-based or priority-based set of synchronous standbys."
Thoughts?
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Konstantin Knizhnik | 2019-07-16 06:19:47 | Re: Built-in connection pooler |
Previous Message | Amit Kapila | 2019-07-16 05:01:39 | Re: POC: Cleaning up orphaned files using undo logs |