Log Message:
-----------
Change references to pgbench to refer to &pgbench; to have common
handling of that entity...

Modified Files:
--------------
    slony1-engine/doc/adminguide:
        firstdb.sgml (r1.15 -> r1.16)

-------------- next part --------------
Index: firstdb.sgml
===================================================================
RCS file: /usr/local/cvsroot/slony1/slony1-engine/doc/adminguide/firstdb.sgml,v
retrieving revision 1.15
retrieving revision 1.16
diff -Ldoc/adminguide/firstdb.sgml -Ldoc/adminguide/firstdb.sgml -u -w -r1.15 -r1.16
--- doc/adminguide/firstdb.sgml
+++ doc/adminguide/firstdb.sgml
@@ -3,26 +3,29 @@
 
 <indexterm><primary>replicating a first database</primary></indexterm>
 
-<para>In this example, we will be replicating a brand new pgbench
-database.  The mechanics of replicating an existing database are
-covered here, however we recommend that you learn how &slony1;
-functions by using a fresh new non-production database.</para>
-
-<para> Note that <application>pgbench</application> is a "benchmark"
-tool that is in the &postgres; set of <filename>contrib</filename>
-tools. If you build &postgres; from source, you can readily head
-to <filename>contrib/pgbench</filename> and do a <command>make
-install</command> to build and install it; it is not always included in
-packaged binary &postgres; installations.</para>
+<para>In this example, we will be replicating a brand new
+<application>pgbench</application> database.  The mechanics of
+replicating an existing database are covered here, however we
+recommend that you learn how &slony1; functions by using a fresh new
+non-production database.</para>
+
+<para> Note that <application>pgbench</application> is a
+<quote>benchmark</quote> tool that is in the &postgres; set of
+<filename>contrib</filename> tools. If you build &postgres; from
+source, you can readily head to <filename>contrib/pgbench</filename>
+and do a <command>make install</command> to build and install it; you
+may discover that included in packaged binary &postgres;
+installations.</para>
 
 <para>The &slony1; replication engine is trigger-based, allowing us to
 replicate databases (or portions thereof) running under the same
 postmaster.</para>
 
-<para>This example will show how to replicate the pgbench database
-running on localhost (master) to the pgbench slave database also
-running on localhost (slave).  We make a couple of assumptions about
-your &postgres; configuration:
+<para>This example will show how to replicate the
+<application>pgbench</application> database running on localhost
+(master) to the <application>pgbench</application> slave database also running on localhost
+(slave).  We make a couple of assumptions about your &postgres;
+configuration:
 
 <itemizedlist>
 
@@ -76,7 +79,7 @@
 </warning></para>
 
 
-<sect2><title>Creating the pgbenchuser</title>
+<sect2><title>Creating the <application>pgbench</application> user</title>
 
 <para><command>
 createuser -A -D $PGBENCHUSER
@@ -138,7 +141,7 @@
 tool. It is a specialized scripting aid that mostly calls stored
 procedures in the master/slave (node) databases.  The script to create
 the initial configuration for the simple master-slave setup of our
-pgbench database looks like this:
+<application>pgbench</application> database looks like this:
 
 <programlisting>
 #!/bin/sh
@@ -227,9 +230,9 @@
 are seeing is the synchronization of cluster configurations between
 the 2 <xref linkend="slon"> processes.</para>
 
-<para>To start replicating the 4 pgbench tables (set 1) from the
-master (node id 1) the the slave (node id 2), execute the following
-script.
+<para>To start replicating the 4 <application>pgbench</application>
+tables (set 1) from the master (node id 1) the the slave (node id 2),
+execute the following script.
 
 <programlisting>
 #!/bin/sh
@@ -255,12 +258,14 @@
 _EOF_
 </programlisting>
 </para>
-<para>Any second now, the replication daemon on <envar>$SLAVEHOST</envar> will start
-to copy the current content of all 4 replicated tables.  While doing
-so, of course, the pgbench application will continue to modify the
-database.  When the copy process is finished, the replication daemon
-on <envar>$SLAVEHOST</envar> will start to catch up by applying the
-accumulated replication log.  It will do this in little steps, 10
+
+<para>Any second now, the replication daemon on
+<envar>$SLAVEHOST</envar> will start to copy the current content of
+all 4 replicated tables.  While doing so, of course, the
+<application>pgbench</application> application will continue to modify
+the database.  When the copy process is finished, the replication
+daemon on <envar>$SLAVEHOST</envar> will start to catch up by applying
+the accumulated replication log.  It will do this in little steps, 10
 seconds worth of application work at a time.  Depending on the
 performance of the two systems involved, the sizing of the two
 databases, the actual transaction load and how well the two databases