Update failover docs, per suggestions from Chris Browne.

diff --git a/doc/src/sgml/failover.sgml b/doc/src/sgml/failover.sgml
index 36819a2b9c57bbfdc0e69ba563ea8e4ac5fbc210..664c92f2e7345571f67198cb53f1a2cf14ffcd20 100644 (file)
--- a/doc/src/sgml/failover.sgml
+++ b/doc/src/sgml/failover.sgml
@@ -1,4 +1,4 @@
-
+
 
 
  Failover, Replication, Load Balancing, and Clustering Options
@@ -108,7 +108,7 @@
   
 
   
-   Slony is an example of this type of replication, with per-table
+   Slony-I is an example of this type of replication, with per-table
    granularity.  It updates the backup server in batches, so the replication
    is asynchronous and might lose data during a fail over.
   
@@ -138,8 +138,8 @@
 
   
    Data partitioning is usually handled by application code, though rules
-   and triggers can be used to keep the read-only data sets current.  Slony
-   can also be used in such a setup.  While Slony replicates only entire
+   and triggers can be used to keep the read-only data sets current.  Slony-I
+   can also be used in such a setup.  While Slony-I replicates only entire
    tables, London and Paris can be placed in separate tables, and
    inheritance can be used to access both tables using a single table name.
   
@@ -158,11 +158,13 @@
   
 
   
-   This can be complex to set up because functions like random()
-   and CURRENT_TIMESTAMP will have different values on different
-   servers, and sequences should be consistent across servers.
-   Care must also be taken that all transactions either commit or
-   abort on all servers  Pgpool is an example of this type of
+   Because each server operates independently, functions like
+   random(), CURRENT_TIMESTAMP, and
+   sequences can have different values on different servers.  If
+   this is unacceptable, applications must query such values from
+   a single server and then use those values in write queries.
+   Also, care must also be taken that all transactions either commit
+   or abort on all servers  Pgpool is an example of this type of
    replication.
   
  
@@ -173,13 +175,23 @@
   
    In clustering, each server can accept write requests, and these
    write requests are broadcast from the original server to all
-   other servers before each transaction commits.  Under heavy
-   load, this can cause excessive locking and performance degradation.
-   It is implemented by Oracle in their
+   other servers before each transaction commits.  Heavy write
+   activity can cause excessive locking, leading to poor performance.
+   In fact, write performance is often worse than that of a single
+   server.  Read requests can be sent to any server.  Clustering
+   is best for mostly read workloads, though its big advantage is
+   that any server can accept write requests --- there is no need
+   to partition workloads between read/write and read-only servers.
+  
+
+  
+   Clustering is implemented by Oracle in their
    RAC product.  PostgreSQL
    does not offer this type of load balancing, though
-   PostgreSQL two-phase commit can be used to
-   implement this in application code or middleware.
+   PostgreSQL two-phase commit (
+   linkend="sql-prepare-transaction-title"> and 
+   "sql-commit-prepared-title">) can be used to implement this in
+   application code or middleware.
   
  
 
@@ -187,12 +199,12 @@
   Clustering For Parallel Query Execution
 
   
-   This allows multiple servers to work on a single query.  One
-   possible way this could work is for the data to be split among
-   servers and for each server to execute its part of the query
-   and results sent to a central server to be combined and returned
-   to the user.  There currently is no PostgreSQL
-   open source solution for this.
+   This allows multiple servers to work concurrently on a single
+   query.  One possible way this could work is for the data to be
+   split among servers and for each server to execute its part of
+   the query and results sent to a central server to be combined
+   and returned to the user.  There currently is no
+   PostgreSQL open source solution for this.