Re: pg_receivewal documentation

From: Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com>
To: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_receivewal documentation
Date: 2019-07-16 17:03:12
Message-ID: 65c3ecdf-8995-34cb-83c4-50068877e632@redhat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 7/16/19 12:28 PM, Laurenz Albe wrote:
>> 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."
>
> I think this would be overly complicated.
> The wording above seems to cover the priority-based base sufficiently
> in my opinion.
> Maybe a second sentence with more detail would be better:
>
> ... 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>.
>

Here is the patch for that.

Best regards,
Jesper

Attachment Content-Type Size
v5_pgreceivewal-doc.patch text/x-patch 1.6 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2019-07-16 17:21:54 Re: heapam_index_build_range_scan's anyvisible
Previous Message Jesper Pedersen 2019-07-16 16:53:53 Re: Index Skip Scan