New async/sync multi-master headings for docs.

doc/src/sgml/high-availability.sgml

-<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.9 2006/11/22 03:44:52 momjian Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.10 2006/11/22 04:00:19 momjian Exp $ -->
 
 <chapter id="high-availability">
  <title>High Availability and Load Balancing</title>
@@ -184,22 +184,22 @@ protocol to make nodes agree on a serializable transactional order.
  </varlistentry>
 
  <varlistentry>
-  <term>Multi-Master Clustering</term>
+  <term>Multi-Master Replication</term>
   <listitem>
 
    <para>
-    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.  Some
-    implementations use cluster-wide shared memory or shared disk
-    to reduce the communication overhead.  Clustering is best for
-    mostly read workloads, though its big advantage is that any
-    server can accept write requests &mdash; there is no need to
-    partition workloads between master and slave servers, and
-    because the data changes are sent from one server to another,
+    In multi-master replication, 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.  Some implementations use cluster-wide shared memory
+    or shared disk to reduce the communication overhead.  Clustering
+    is best for mostly read workloads, though its big advantage is
+    that any server can accept write requests &mdash; there is no
+    need to partition workloads between master and slave servers,
+    and because the data changes are sent from one server to another,
     there is no problem with non-deterministic functions like
     <function>random()</>.
    </para>
@@ -246,7 +246,7 @@ protocol to make nodes agree on a serializable transactional order.
  </varlistentry>
 
  <varlistentry>
-  <term>Clustering For Parallel Query Execution</term>
+  <term>Multi-Server Parallel Query Execution</term>
   <listitem>
 
    <para>