Re: pg_receivewal documentation

From: Jehan-Guillaume de Rorthais <jgdr(at)dalibo(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_receivewal documentation
Date: 2019-07-25 08:29:44
Message-ID: 20190725102944.79a0be92@firost
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 25 Jul 2019 16:58:17 +0900
Michael Paquier <michael(at)paquier(dot)xyz> wrote:

> On Wed, Jul 24, 2019 at 03:03:04PM +0200, Jehan-Guillaume de Rorthais wrote:
> > Unless I am missing something, another solution might be to use a dedicated
> > role to pg_receive{xlog|wal} with synchronous_commit lower than
> > remote_apply.
>
> Aren't you confused by the same thing as I was upthread [1]?
> [1]: https://www.postgresql.org/message-id/20190710080423.GG1031@paquier.xyz
>
> remote_apply affects all sessions. So even if you use a replication
> role with synchronous_commit = on and have pg_receivewal use that with
> remote_apply set in postgresql.conf, then remote_apply is effective
> for all the other sessions so these will still be stuck at commit
> waiting for pg_receivewal to apply WAL if it is a synchronous
> standby.

Argh!

(Sorry for the noise)

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Julien Rouhaud 2019-07-25 08:42:11 Re: Add parallelism and glibc dependent only options to reindexdb
Previous Message Dent John 2019-07-25 08:17:54 add_path() for Path without InitPlan: cost comparison vs. Paths that require one