Synchronous logical replication?

From: Arseny Sher <a(dot)sher(at)postgrespro(dot)ru>
To: pgsql-docs(at)postgresql(dot)org
Subject: Synchronous logical replication?
Date: 2017-06-25 19:07:38
Message-ID: 877ezznax1.fsf@ars-thinkpad
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs

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.
1) I failed to find in the docs whether logical replication supports
synchronous mode at all and how it is configured.
2) Assuming it is supported, how setting synchronous_commit to off on
replica (subscriber) can increase COMMIT latency on master?
Obviously synchronous mode itself does increase it, but
- In physical replication (docs for synchronous_commit in section
19.5.1) only master's synchronous_commit value determines what
it waits for (e.g. 'remote_write' means writing to replica's OS),
and it seems natural to expect the same behaviour from logical
replication
- Even if replica's synchronous_commit somehow influences this,
'off' value is the lowest and fastest, isn't it?

Arseny Sher
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

Responses

Browse pgsql-docs by date

  From Date Subject
Next Message Noah Misch 2017-06-26 04:26:28 Re: gen_random_uuid security not explicit in documentation
Previous Message Kurt Kartaltepe 2017-06-25 03:20:10 Suggested changes to plpgsql-structure section of plpgsql