Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256)
	(Exim 4.89)
	(envelope-from <pgsql-docs-owner+archive@lists.postgresql.org>)
	id 1iED4d-0007eH-FR
	for pgsql-docs@arkaria.postgresql.org; Sat, 28 Sep 2019 13:47:47 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.89)
	(envelope-from <pgsql-docs-owner+archive@lists.postgresql.org>)
	id 1iED4c-0006bb-Bd
	for pgsql-docs@arkaria.postgresql.org; Sat, 28 Sep 2019 13:47:46 +0000
Received: from makus.postgresql.org ([2001:4800:3e1:1::229])
	by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256)
	(Exim 4.89)
	(envelope-from <bruce@momjian.us>)
	id 1iED4c-0006aV-1l
	for pgsql-docs@lists.postgresql.org; Sat, 28 Sep 2019 13:47:46 +0000
Received: from momjian.us ([72.94.173.45])
	by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <bruce@momjian.us>)
	id 1iED4Z-0002uD-Qv
	for pgsql-docs@lists.postgresql.org; Sat, 28 Sep 2019 13:47:44 +0000
Received: from bruce by momjian.us with local (Exim 4.92)
	(envelope-from <bruce@momjian.us>)
	id 1iED4W-0003y3-8W; Sat, 28 Sep 2019 09:47:40 -0400
Date: Sat, 28 Sep 2019 09:47:40 -0400
From: Bruce Momjian <bruce@momjian.us>
To: juha-pekka.eloranta@reaktor.fi, pgsql-docs@lists.postgresql.org
Subject: Re: Synchronous Multimaster Replication
Message-ID: <20190928134740.GB26853@momjian.us>
References: <156856543824.1274.12180817186798859836@wrigleys.postgresql.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="qMm9M+Fa2AknHoGS"
Content-Disposition: inline
In-Reply-To: <156856543824.1274.12180817186798859836@wrigleys.postgresql.org>
User-Agent: Mutt/1.10.1 (2018-07-13)
List-Id: <pgsql-docs.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-docs@lists.postgresql.org>
List-Owner: <mailto:pgsql-docs-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-docs>
Precedence: bulk


--qMm9M+Fa2AknHoGS
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Sun, Sep 15, 2019 at 04:37:18PM +0000, PG Doc comments form wrote:
> The following documentation comment has been logged on the website:
> 
> Page: https://www.postgresql.org/docs/11/different-replication-solutions.html
> Description:
> 
> Not sure if this is an error but I was wondering about this sentence: "In
> fact, write performance is often worse than that of a single server". Isn't
> syncronous multimaster write performance always (rather than "often") worse
> than that of a single (non-distributed) server?

Very good point. I have improved the text with the attached patch.  I
also clarified the asynchronous case.

-- 
  Bruce Momjian  <bruce@momjian.us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +

--qMm9M+Fa2AknHoGS
Content-Type: text/x-diff; charset=us-ascii
Content-Disposition: attachment; filename="sync.diff"

diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
new file mode 100644
index 43bcb2a..a42541f
*** a/doc/src/sgml/high-availability.sgml
--- b/doc/src/sgml/high-availability.sgml
*************** protocol to make nodes agree on a serial
*** 237,243 ****
     <listitem>
  
      <para>
!      For servers that are not regularly connected, like laptops or
       remote servers, keeping data consistent among servers is a
       challenge.  Using asynchronous multimaster replication, each
       server works independently, and periodically communicates with
--- 237,244 ----
     <listitem>
  
      <para>
!      For servers that are not regularly connected or have slow
!      communication links, like laptops or
       remote servers, keeping data consistent among servers is a
       challenge.  Using asynchronous multimaster replication, each
       server works independently, and periodically communicates with
*************** protocol to make nodes agree on a serial
*** 256,264 ****
       In synchronous multimaster replication, each server can accept
       write requests, and modified data is transmitted from the
       original server to every other server before each transaction
!      commits.  Heavy write activity can cause excessive locking,
!      leading to poor performance.  In fact, write performance is
!      often worse than that of a single server.  Read requests can
       be sent to any server.  Some implementations use shared disk
       to reduce the communication overhead.  Synchronous multimaster
       replication is best for mostly read workloads, though its big
--- 257,264 ----
       In synchronous multimaster replication, each server can accept
       write requests, and modified data is transmitted from the
       original server to every other server before each transaction
!      commits.  Heavy write activity can cause excessive locking and
!      commit delays, leading to poor performance.  Read requests can
       be sent to any server.  Some implementations use shared disk
       to reduce the communication overhead.  Synchronous multimaster
       replication is best for mostly read workloads, though its big

--qMm9M+Fa2AknHoGS--