Some minor wordsmithing for the cascading replication documentation.

Per report from Thom Brown.

diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index 8bcdc07a763a889058a0dc1bd4ad95abca496e0b..86c2729cfd3f7fbaae38e1a2057847f81f5be56b 100644 (file)
--- a/doc/src/sgml/high-availability.sgml
+++ b/doc/src/sgml/high-availability.sgml
@@ -924,16 +924,17 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
     Promoting a cascading standby terminates the immediate downstream replication
     connections which it serves. This is because the timeline becomes different
     between standbys, and they can no longer continue replication.  The
-    effected standby(s) may reconnect to reestablish streaming replication.
+    affected standby(s) may reconnect to reestablish streaming replication.
    
 
    
     To use cascading replication, set up the cascading standby so that it can
-    accept replication connections, i.e., set max_wal_senders,
-    hot_standby and authentication option (see
-     and ).
-    Also set primary_conninfo in the downstream standby to point
-    to the cascading standby.
+    accept replication connections (that is, set
+     and ,
+    and configure
+    host-based authentication).
+    You will also need to set primary_conninfo in the downstream
+    standby to point to the cascading standby.