Some high-availability.sgml improvements.
thanks,
Erik Rijkers
--- doc/src/sgml/high-availability.sgml.orig 2011-03-17 19:57:28.0 +0100
+++ doc/src/sgml/high-availability.sgml 2011-03-17 20:15:37.0 +0100
@@ -873,7 +873,7 @@
might indicate that the master server is under heavy load, while
differences between sent_location and
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.
@@ -946,13 +946,13 @@
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
wal_receiver_status_interval is set to zero on the standby.
If the standby is the first matching standby, as specified in
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 synchronous_commit is used when the user
specifies synchronous_replication, overriding even an
explicit setting of synchronous_commit to 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.
@@ -1002,7 +1002,7 @@
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 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.
@@ -1040,7 +1040,7 @@
we move to real-time 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 STREAMING state.
@@ -1064,15 +1064,15 @@
-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.
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
+synchronous_replication = off, otherwise those requests will wait
forever for the standby to appear.
@@ -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 trigger_file
setting in recovery.conf. If you're planning to use
pg_ctl promote to fail over, 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 p
