Minor fixes for high availability documentation.

Erik Rijkers and me

doc/src/sgml/high-availability.sgml

@@ -873,7 +873,7 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
      might indicate that the master server is under heavy load, while
      differences between <literal>sent_location</> and 
      <function>pg_last_xlog_receive_location</> on the standby might indicate
-     network delay, or that the the standby is under heavy load.
+     network delay, or that the standby is under heavy load.
     </para>
    </sect3>
 
@@ -952,7 +952,7 @@ synchronous_replication = on
     If the standby is the first matching standby, as specified in
     <varname>synchronous_standby_names</> on the primary, the reply
     messages from that standby will be used to wake users waiting for
-    confirmation the commit record has been received. These parameters
+    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
     replication is mainly on the master.
@@ -1002,10 +1002,10 @@ synchronous_replication = on
 
    <para>
     With synchronous replication options specified at the application level
-    (on the primary) we can offer sync rep for the most important changes,
+    (on the primary) we can offer synchronous replication for the most
-    without slowing down the bulk of the total workload. Application level
+    important changes, without slowing down the bulk of the total workload.
-    options are an important and practical tool for allowing the benefits of
+    Application level options are an important and practical tool for allowing
-    synchronous replication for high performance applications.
+    the benefits of synchronous replication for high performance applications.
    </para>
 
    <para>
@@ -1060,11 +1060,12 @@ synchronous_replication = on
 
    <para>
     If you really do lose your last standby server then you should disable
-    <varname>synchronous_standby_names</> and restart the primary server.
+    <varname>synchronous_standby_names</> and reload the configuration file
+    on the primary server.
    </para>
 
    <para>
-    If the primary is isolated from remaining standby severs you should
+    If the primary is isolated from remaining standby servers you should
     fail over to the best candidate of those other remaining standby servers.
    </para>
 
@@ -1130,7 +1131,7 @@ synchronous_replication = on
     and might stay down.  To return to normal operation, a standby server
     must be recreated,
     either on the former primary system when it comes up, or on a third,
-    possibly new, system. Once complete the primary and standby can be
+    possibly new, system. Once complete, the primary and standby can be
     considered to have switched roles. Some people choose to use a third
     server to provide backup for the new primary until the new standby
     server is recreated,
@@ -1155,8 +1156,7 @@ synchronous_replication = on
     <command>pg_ctl promote</> to fail over, <varname>trigger_file</> is
     not required. If you're setting up the reporting servers that are
     only used to offload read-only queries from the primary, not for high
-    availability purposes, you don't need to exit recovery in the standby
+    availability purposes, you don't need to promote it.
-    and promote it to a master.
    </para>
   </sect1>