Minor markup improvements for Hot Standby documentation.

diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 75127f972dea324f9f61ba8f84b9332d5a0afe8e..298ccb60e1d0e4547ba6c1cd87be8a656d0fbbdc 100644 (file)
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.281 2010/06/15 07:52:10 itagaki Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.282 2010/06/22 02:57:49 rhaas Exp $ -->
 
 <chapter Id="runtime-config">
   <title>Server Configuration</title>
@@ -1977,14 +1977,14 @@ SET ENABLE_SEQSCAN TO OFF;
         <acronym>HOT</> updates will defer cleanup of dead row versions. The
         default is 0 transactions, meaning that dead row versions will be
         removed as soon as possible. You may wish to set this to a non-zero
-        value when planning or maintaining a <xref linkend="hot-standby">
-        configuration. The recommended value is <literal>0</> unless you have
-        clear reason to increase it. The purpose of the parameter is to
-        allow the user to specify an approximate time delay before cleanup
-        occurs. However, it should be noted that there is no direct link with
-        any specific time delay and so the results will be application and
-        installation specific, as well as variable over time, depending upon
-        the transaction rate (of writes only).
+        value when planning or maintaining a Hot Standby connection, as
+        described in <xref linkend="hot-standby">.  The recommended value is
+        <literal>0</> unless you have clear reason to increase it. The purpose
+        of the parameter is to allow the user to specify an approximate time
+        delay before cleanup occurs. However, it should be noted that there is
+        no direct link with any specific time delay and so the results will be
+        application and installation specific, as well as variable over time,
+        depending upon the transaction rate (of writes only).
        </para>
       </listitem>
      </varlistentry>

diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index 2ac79245d028c778aad82248d1c2ad3c3afcb2ec..b94c19988f9a566be50b31e66603a829981bd229 100644 (file)
--- a/doc/src/sgml/high-availability.sgml
+++ b/doc/src/sgml/high-availability.sgml
@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.73 2010/06/11 10:13:08 heikki Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.74 2010/06/22 02:57:50 rhaas Exp $ -->
 
 <chapter id="high-availability">
  <title>High Availability, Load Balancing, and Replication</title>
@@ -1330,7 +1330,7 @@ if (!triggered)
      </listitem>
      <listitem>
       <para>
-       LISTEN, UNLISTEN, NOTIFY
+       <command>LISTEN</>, <command>UNLISTEN</>, <command>NOTIFY</>
       </para>
      </listitem>
     </itemizedlist>
@@ -1437,14 +1437,14 @@ if (!triggered)
     Some WAL redo actions will be for <acronym>DDL</> execution. These DDL
     actions are replaying changes that have already committed on the primary
     node, so they must not fail on the standby node. These DDL locks take
-    priority and will automatically *cancel* any read-only transactions that
-    get in their way, after a grace period. This is similar to the possibility
-    of being canceled by the deadlock detector.  But in this case, the standby
-    recovery process always wins, since the replayed actions must not fail.
-    This also ensures that replication does not fall behind while waiting for a
-    query to complete. This prioritization presumes that the standby exists
-    primarily for high availability, and that adjusting the grace period
-    will allow a sufficient guard against unexpected cancellation.
+    priority and will automatically <emphasis>cancel</> any read-only
+    transactions that get in their way, after a grace period. This is similar
+    to the possibility of being canceled by the deadlock detector.  But in this
+    case, the standby recovery process always wins, since the replayed actions
+    must not fail.  This also ensures that replication does not fall behind
+    while waiting for a query to complete. This prioritization presumes that
+    the standby exists primarily for high availability, and that adjusting the
+    grace period will allow a sufficient guard against unexpected cancellation.
    </para>
 
    <para>