Update Statement-Based Replication Middleware docs to be more general.

diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index d3ef45944f7e5638308689dd16c81364227f6803..ccdfd8d1cb5183e1621e0de033e57043ec98eb61 100644 (file)
--- a/doc/src/sgml/high-availability.sgml
+++ b/doc/src/sgml/high-availability.sgml
@@ -1,4 +1,4 @@
-
+
 
 
  High Availability and Load Balancing
@@ -166,16 +166,16 @@ protocol to make nodes agree on a serializable transactional order.
    
 
    
-    One limitation of this solution is that functions like
+    If queries are simply broadcast unmodified, functions like
     random(), CURRENT_TIMESTAMP, and
-    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, perhaps using two-phase commit (
-    linkend="sql-prepare-transaction"
+    sequences would 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, either the middleware or the application
+    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, perhaps
+    using two-phase commit (linkend="sql-prepare-transaction"
     endterm="sql-prepare-transaction-title"> and 
     linkend="sql-commit-prepared" endterm="sql-commit-prepared-title">.
     Pgpool is an example of this type of replication.