Re: pg_receivewal documentation

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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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."


In response to


Browse pgsql-hackers by date

  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