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 @@
-
+
 
 
   Server Configuration
@@ -1977,14 +1977,14 @@ SET ENABLE_SEQSCAN TO OFF;
         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 
-        configuration. The recommended value is 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 .  The recommended value is
+        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).
        
       
      

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 @@
-
+
 
 
  High Availability, Load Balancing, and Replication
@@ -1330,7 +1330,7 @@ if (!triggered)
      
      
       
-       LISTEN, UNLISTEN, NOTIFY
+       LISTEN, UNLISTEN, NOTIFY
       
      
     
@@ -1437,14 +1437,14 @@ if (!triggered)
     Some WAL redo actions will be for 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 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.