Re: pg_receivewal documentation

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

In response to

Responses

Browse pgsql-hackers by date

  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