Re: pg_receivewal documentation

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, 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-23 00:08:20
Message-ID: 20190723000820.GA2059@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Jul 22, 2019 at 01:25:41PM -0400, Jesper Pedersen wrote:
> Hi,
>
> On 7/21/19 9:48 PM, Michael Paquier wrote:
> > > Since pg_receivewal does not apply WAL, you should not allow it to
> > > become a synchronous standby when synchronous_commit = remote_apply.
> > > If it does, it will appear to be a standby which never catches up,
> > > which may cause commits to block. To avoid this, you should either
> > > configure an appropriate value for synchronous_standby_names, or
> > > specify an application_name for pg_receivewal that does not match it,
> > > or change the value of synchronous_commit to something other than
> > > remote_apply.
> > >
> > > I think that'd be a lot more useful than enumerating the total-failure
> > > scenarios.
> >
> > +1. Thanks for the suggestions! Your wording looks good to me.
>
> +1
>
> Here is the patch for it, with Robert as the author.

> + <xref linkend="guc-synchronous-commit"/> to something other than

Looks fine to me. Just a tiny nit. For the second reference to
synchronous_commit, I would change the link to a <varname> markup.
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Matsumura, Ryo 2019-07-23 00:40:43 RE: [Patch] PQconnectPoll() is blocked if target_session_attrs is read-write
Previous Message Thomas Munro 2019-07-22 23:25:43 Re: errbacktrace