From: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
To: Arseny Sher <a.sher@postgrespro.ru>
To: pgsql-docs@postgresql.org
Subject: Re: Synchronous logical replication?
Date: Sun, 2 Jul 2017 00:19:44 -0400
Message-ID: <7fb9fc7c-72f7-f9ef-3896-9cc7e4fd13b0@2ndquadrant.com> (raw)
In-Reply-To: <877ezznax1.fsf@ars-thinkpad>
References: <877ezznax1.fsf@ars-thinkpad>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-docs>
On 6/25/17 15:07, Arseny Sher wrote:
> devel version of the manual (2017-06-25 12:17:02) contains the following
> paragraph documenting the CREATE SUBSCRIPTION command:
>
> synchronous_commit (enum)
>
> ....
>
> A different setting might be appropriate when doing synchronous
> logical replication. The logical replication workers report the
> positions of writes and flushes to the publisher, and when using
> synchronous replication, the publisher will wait for the actual
> flush. This means that setting synchronous_commit for the subscriber
> to off when the subscription is used for synchronous replication
> might increase the latency for COMMIT on the publisher. In this
> scenario, it can be advantageous to set synchronous_commit to local
> or higher.
>
> It seems to me quite confusing.
It is.
> 1) I failed to find in the docs whether logical replication supports
> synchronous mode at all and how it is configured.
I have added some information about that.
> 2) Assuming it is supported, how setting synchronous_commit to off on
> replica (subscriber) can increase COMMIT latency on master?
The synchronous_commit setting for a subscription determines what
happens to the things that the subscription's apply worker writes
locally. The subscription's apply worker operates much like a normal
client backend, and whatever it writes and commits is subject to its
local current synchronous_commit setting.
In most cases, synchronous_commit off is the best setting because it
avoids the flushing work at commit time, and it is safe because in case
of a crash the data can be re-obtained from the publishing server.
But if you use synchronous replication on the publishing server, then
the publishing server will wait for the subscribing server to send
feedback messages when the sent data has been flushed to disk on the
subscribing server (depending on the particular setting). If the
subscriber has synchronous_commit off, then the flushing happens at some
random later time, and then the upstream publisher has to wait for that
to happen. In order to speed that up, you need to make the subscriber
flush stuff faster, and the way to do that is to set synchronous_commit
to a value other than off on the subscriber.
The reason for this confusion is that synchronous_commit has both a
local and a remote meaning, and in this case the local meaning on the
subscriber has an impact on the remote meaning of the publisher.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-docs mailing list (pgsql-docs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-docs
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-docs@postgresql.org
Cc: peter.eisentraut@2ndquadrant.com, a.sher@postgrespro.ru
Subject: Re: Synchronous logical replication?
In-Reply-To: <7fb9fc7c-72f7-f9ef-3896-9cc7e4fd13b0@2ndquadrant.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox