Message-ID: <2b40228e696e6a57c1e19fe2f12269e4.squirrel@webmail.xs4all.nl>
Date: Thu, 17 Mar 2011 20:29:58 +0100
Subject: high-availability.sgml improvements
From: "Erik Rijkers" <er@xs4all.nl>
To: pgsql-docs@postgresql.org
User-Agent: SquirrelMail/1.4.18
MIME-Version: 1.0
Content-Type: multipart/mixed;boundary="----=_20110317202958_90478"

------=_20110317202958_90478
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit

Some high-availability.sgml improvements.

thanks,

Erik Rijkers

------=_20110317202958_90478
Content-Type: text/x-patch; name="high-availability.sgml.diff"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment; filename="high-availability.sgml.diff"

--- doc/src/sgml/high-availability.sgml.orig	2011-03-17 19:57:28.000000000 +0100
+++ doc/src/sgml/high-availability.sgml	2011-03-17 20:15:37.000000000 +0100
@@ -873,7 +873,7 @@
      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 thendby is under heavy load.
     </para>
    </sect3>
 
@@ -946,13 +946,13 @@
 
    <para>
     After a commit record has been written to disk on the primary the
-    WAL record is then sent to the standby. The standby sends reply
+    WAL record is sent to the standby. The standby sends reply
     messages each time a new batch of WAL data is received, unless
     <varname>wal_receiver_status_interval</> is set to zero on the standby.
     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.
@@ -968,7 +968,7 @@
     Note also that <varname>synchronous_commit</> is used when the user
     specifies <varname>synchronous_replication</>, overriding even an
     explicit setting of <varname>synchronous_commit</> to <literal>off</>.
-    This is because we must write WAL to disk on primary before we replicate
+    This is because WAL must be written to disk on the primary before replication
     to ensure the standby never gets ahead of the primary.
    </para>
 
@@ -1002,7 +1002,7 @@
 
    <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 important changes,
     without slowing down the bulk of the total workload. Application level
     options are an important and practical tool for allowing the benefits of
     synchronous replication for high performance applications.
@@ -1029,7 +1029,7 @@
     your last remaining sync standby. This can be achieved by naming multiple
     potential synchronous standbys using <varname>synchronous_standby_names</>.
     The first named standby will be used as the synchronous standby. Standbys
-    listed after this will takeover the role of synchronous standby if the
+    listed after this will take over the role of synchronous standby if the
     first one should fail.
    </para>
 
@@ -1040,7 +1040,7 @@
     we move to real-time <literal>STREAMING</> state.
     The catch-up duration may be long immediately after the standby has
     been created. If the standby is shutdown, then the catch-up period
-    will increase according to the length of time the standby has been down.
+    will increase according to the length of time the standby is down.
     The standby is only able to become a synchronous standby
     once it has reached <literal>STREAMING</> state.
    </para>
@@ -1064,15 +1064,15 @@
    </para>
 
    <para>
-    If the primary is isolated from remaining standby severs you should
-    failover to the best candidate of those other remaining standby servers.
+    If the primary is isolated from remaining standby servers you should
+    failover to the best candidate of the remaining standby servers.
    </para>
 
    <para>
     If you need to re-create a standby server while transactions are
     waiting, make sure that the commands to run pg_start_backup() and
     pg_stop_backup() are run in a session with
-    synchronous_replication = off, otherwise those requests will wait
+    <literal>synchronous_replication = off</>, otherwise those requests will wait
     forever for the standby to appear.
    </para>
 
@@ -1130,7 +1130,7 @@
     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,
@@ -1153,7 +1153,7 @@
     file with the filename and path specified by the <varname>trigger_file</>
     setting in <filename>recovery.conf</>. If you're planning to use
     <command>pg_ctl promote</> to fail over, <varname>trigger_file</> is
-    not required. If you're setting up the reporting servers that are
+    not required. If you're setting up 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
     and promote it to a master.
------=_20110317202958_90478--