Improve broadcast wording for failover/clustering documentation.

diff --git a/doc/src/sgml/failover.sgml b/doc/src/sgml/failover.sgml
index 38e0fd6b076b77aae6cf12a1f18633bf930a80f5..45cafc990f1201bcb4729c63b4cb17442322548d 100644 (file)
--- a/doc/src/sgml/failover.sgml
+++ b/doc/src/sgml/failover.sgml
@@ -149,23 +149,25 @@
   <title>Query Broadcast Load Balancing</title>
 
   <para>
-   Query broadcast load balancing is accomplished by having a program
-   intercept every query and send it to all servers.  Read-only queries can
-   be sent to a single server because there is no need for all servers to
-   process it.  This is unusual because most replication solutions have
-   each write server propagate its changes to the other servers.  With
-   query broadcasting, each server operates independently.
+   Query broadcast load balancing is accomplished by having a
+   program intercept every SQL query and send it to all servers.
+   This is unique because most replication solutions have the write
+   server propagate its changes to the other servers.  With query
+   broadcasting, each server operates independently.  Read-only
+   queries can be sent to a single server because there is no need
+   for all servers to process it.
   </para>
 
   <para>
-   Because each server operates independently, functions like
+   One limitation of this solution is that functions like
    <function>random()</>, <function>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.
+   sequences can have different values on different servers.  This
+   is because each server operates independently, and because SQL
+   queries are broadcast (and not actual modified rows).  If this
+   is unacceptable, applications must query such values from a
+   single server and then use those values in write queries.  Also,
+   care must be taken that all transactions either commit or abort
+   on all servers  Pgpool is an example of this type of replication.
   </para>
  </sect1>
 
@@ -173,14 +175,14 @@
   <title>Clustering For Load Balancing</title>
 
   <para>
-   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.  Heavy write
-   activity can cause excessive locking, leading to poor performance.
-   In fact, write performance is often worse than that of a single
+   In clustering, each server can accept write requests, and modified
+   data is transmitted from the original server to every other
+   server 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
+   that any server can accept write requests &mdash; there is no need
    to partition workloads between read/write and read-only servers.
   </para>