Fix a couple of places in doc that implied there was only one sync standby.

Thomas Munro

1 files changed, 7 insertions, 6 deletions

diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index d87a57e1c20..7ceb5881400 100644
--- a/doc/src/sgml/high-availability.sgml
+++ b/doc/src/sgml/high-availability.sgml
@@ -1086,9 +1086,10 @@ 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 the synchronous standby, from a priority
+    If the standby is chosen as a synchronous standby, from a priority
     list of <varname>synchronous_standby_names</> on the primary, the reply
-    messages from that standby will be used to wake users waiting for
+    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
     allow the administrator to specify which standby servers should be
     synchronous standbys. Note that the configuration of synchronous
@@ -1113,10 +1114,10 @@ primary_slot_name = 'node_a_slot'
 
    <para>
     Setting <varname>synchronous_commit</> to <literal>remote_apply</> will
-    cause each commit to wait until the current synchronous standby reports
-    that it has replayed the transaction, making it visible to user queries.
-    In simple cases, this allows for load balancing with causal consistency
-    on a single hot standby.
+    cause each commit to wait until the current synchronous standbys report
+    that they have replayed the transaction, making it visible to user
+    queries.  In simple cases, this allows for load balancing with causal
+    consistency.
    </para>
 
    <para>