@@ -1086,9 +1086,10 @@ primary_slot_name = 'node_a_slot'
1086
1086
In the case that <varname>synchronous_commit</> is set to
1087
1087
<literal>remote_apply</>, the standby sends reply messages when the commit
1088
1088
record is replayed, making the transaction visible.
1089
- If the standby is chosen as the synchronous standby, from a priority
1089
+ If the standby is chosen as a synchronous standby, from a priority
1090
1090
list of <varname>synchronous_standby_names</> on the primary, the reply
1091
- messages from that standby will be used to wake users waiting for
1091
+ messages from that standby will be considered along with those from other
1092
+ synchronous standbys to decide when to release transactions waiting for
1092
1093
confirmation that the commit record has been received. These parameters
1093
1094
allow the administrator to specify which standby servers should be
1094
1095
synchronous standbys. Note that the configuration of synchronous
@@ -1113,10 +1114,10 @@ primary_slot_name = 'node_a_slot'
1113
1114
1114
1115
<para>
1115
1116
Setting <varname>synchronous_commit</> to <literal>remote_apply</> will
1116
- cause each commit to wait until the current synchronous standby reports
1117
- that it has replayed the transaction, making it visible to user queries.
1118
- In simple cases, this allows for load balancing with causal consistency
1119
- on a single hot standby .
1117
+ cause each commit to wait until the current synchronous standbys report
1118
+ that they have replayed the transaction, making it visible to user
1119
+ queries. In simple cases, this allows for load balancing with causal
1120
+ consistency .
1120
1121
</para>
1121
1122
1122
1123
<para>
0 commit comments