@@ -919,8 +919,8 @@ postgresql://%2Fvar%2Flib%2Fpostgresql/dbname
919
919
<literal>hostaddr</> corresponds to the first host name, the second
920
920
<literal>hostaddr</> corresponds to the second host name, and so
921
921
forth. As an exception, if only one <literal>port</literal> is specified,
922
- it applies to all the hosts. You can define the order in which to
923
- try to connect to the specified hosts using the
922
+ it applies to all the hosts. You can define the order of choosing the
923
+ hosts to connect to using the
924
924
<xref linkend="libpq-connect-hostorder"> parameter.
925
925
</para>
926
926
@@ -1046,7 +1046,7 @@ postgresql://%2Fvar%2Flib%2Fpostgresql/dbname
1046
1046
<term><literal>hostorder</literal></term>
1047
1047
<listitem>
1048
1048
<para>
1049
- Defines the order in which to try to connect to the hosts specified
1049
+ Defines the order of connecting to the hosts specified
1050
1050
by the <xref linkend="libpq-connect-host"> parameter.
1051
1051
</para>
1052
1052
<para>
@@ -1057,8 +1057,8 @@ postgresql://%2Fvar%2Flib%2Fpostgresql/dbname
1057
1057
<para>
1058
1058
If the value is <literal>random</literal>, the host to connect to
1059
1059
is randomly picked from the list. This setting can help you balance
1060
- the load between several cluster nodes instead of always trying to
1061
- connect to one of the first hosts in the list. You can also use the
1060
+ the load between several cluster nodes instead of always connecting
1061
+ to the first available host in the list. You can also use the
1062
1062
<xref linkend="libpq-connect-target-session-attrs"> parameter
1063
1063
to forbid read-only connections.
1064
1064
</para>
0 commit comments