From a790ed9f69ef584c12aec68d0d80e6b6b543bacb Mon Sep 17 00:00:00 2001
From: Fujii Masao <fujii@postgresql.org>
Date: Wed, 19 Apr 2017 02:58:28 +0900
Subject: [PATCH] Improve documentation and comment for quorum-based sync
replication.
Author: Masahiko Sawada, heavily modified by me
Discussion: http://postgr.es/m/CAHGQGwEKOw=SmPLxJzkBsH6wwDBgOnVz46QjHbtsiZ-d-2RGUg@mail.gmail.com
---
doc/src/sgml/high-availability.sgml | 21 ++++++++++++++++-----
src/backend/replication/syncrep.c | 5 +++++
2 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index 51359d6236f..9e2be5f67ca 100644
--- a/doc/src/sgml/high-availability.sgml
+++ b/doc/src/sgml/high-availability.sgml
@@ -1084,8 +1084,8 @@ primary_slot_name = 'node_a_slot'
In the case that <varname>synchronous_commit</> is set to
<literal>remote_apply</>, the standby sends reply messages when the commit
record is replayed, making the transaction visible.
- If the standby is chosen as a synchronous standby, from a priority
- list of <varname>synchronous_standby_names</> on the primary, the reply
+ If the standby is chosen as a synchronous standby, according to the setting
+ of <varname>synchronous_standby_names</> on the primary, the reply
messages from that standby will be considered along with those from other
synchronous standbys to decide when to release transactions waiting for
confirmation that the commit record has been received. These parameters
@@ -1246,9 +1246,20 @@ synchronous_standby_names = 'FIRST 2 (s1, s2, s3)'
The best solution for high availability is to ensure you keep as many
synchronous standbys as requested. This can be achieved by naming multiple
potential synchronous standbys using <varname>synchronous_standby_names</>.
- The standbys whose names appear earlier in the list will be used as
- synchronous standbys. Standbys listed after these will take over
- the role of synchronous standby if one of current ones should fail.
+ </para>
+
+ <para>
+ In a priority-based synchronous replication, the standbys whose names
+ appear earlier in the list will be used as synchronous standbys.
+ Standbys listed after these will take over the role of synchronous standby
+ if one of current ones should fail.
+ </para>
+
+ <para>
+ In a quorum-based synchronous replication, all the standbys appearing
+ in the list will be used as candidates for synchronous standbys.
+ Even if one of them should fail, the other standbys will keep performing
+ the role of candidates of synchronous standby.
</para>
<para>
diff --git a/src/backend/replication/syncrep.c b/src/backend/replication/syncrep.c
index 20a1441f0a7..25c67aaac72 100644
--- a/src/backend/replication/syncrep.c
+++ b/src/backend/replication/syncrep.c
@@ -53,6 +53,10 @@
* in the list. All the standbys appearing in the list are considered as
* candidates for quorum synchronous standbys.
*
+ * If neither FIRST nor ANY is specified, FIRST is used as the method.
+ * This is for backward compatibility with 9.6 or before where only a
+ * priority-based sync replication was supported.
+ *
* Before the standbys chosen from synchronous_standby_names can
* become the synchronous standbys they must have caught up with
* the primary; that may take some time. Once caught up,
@@ -629,6 +633,7 @@ SyncRepGetNthLatestSyncRecPtr(XLogRecPtr *writePtr, XLogRecPtr *flushPtr,
i++;
}
+ /* Sort each array in descending order */
qsort(write_array, len, sizeof(XLogRecPtr), cmp_lsn);
qsort(flush_array, len, sizeof(XLogRecPtr), cmp_lsn);
qsort(apply_array, len, sizeof(XLogRecPtr), cmp_lsn);
--
GitLab