Copy editing of Hot Standby docs. Some clarifications, addition

of missing items and minor edits.

diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index 7fc34603f810f5bcfc56d132474ee616a6c16a4d..535321da392902891c57ec5c075f77c8f1d55014 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.47 2010/02/19 00:15:25 momjian Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.48 2010/02/20 10:07:27 sriggs Exp $ -->
 
 <chapter id="high-availability">
  <title>High Availability, Load Balancing, and Replication</title>
@@ -1079,8 +1079,8 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
     The data on the standby takes some time to arrive from the primary server
     so there will be a measurable delay between primary and standby. Running the
     same query nearly simultaneously on both primary and standby might therefore
-    return differing results. Eventually, the standby will be
-    consistent with the primary.
+    return differing results. We say that data on the standby is
+    <literal>eventually consistent</literal> with the primary.
     Queries executed on the standby will be correct with regard to the transactions
     that had been recovered at the start of the query, or start of first statement
     in the case of serializable transactions. In comparison with the primary,
@@ -1203,12 +1203,12 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
      </listitem>
      <listitem>
       <para>
-       <command>LOCK TABLE</> that explicitly requests a mode higher than <literal>ROW EXCLUSIVE MODE</>.
+       <command>LOCK</> that explicitly requests a mode higher than <literal>ROW EXCLUSIVE MODE</>.
       </para>
      </listitem>
      <listitem>
       <para>
-       <command>LOCK TABLE</> in short default form, since it requests <literal>ACCESS EXCLUSIVE MODE</>.
+       <command>LOCK</> in short default form, since it requests <literal>ACCESS EXCLUSIVE MODE</>.
       </para>
      </listitem>
      <listitem>
@@ -1245,7 +1245,7 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
      </listitem>
      <listitem>
       <para>
-       Sequence update - <function>nextval()</>
+       Sequence updates - <function>nextval()</>, <function>setval()</>
       </para>
      </listitem>
      <listitem>
@@ -1262,8 +1262,7 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
     subtle differences in behavior between read-only transactions
     run on a standby and run during normal operation.
     It is possible that <command>LISTEN</>, <command>UNLISTEN</>,
-    <command>NOTIFY</>, and temporary tables might be allowed in a
-    future release.
+    and temporary tables might be allowed in a future release.
    </para>
 
    <para>
@@ -1483,7 +1482,8 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
     Three-way deadlocks are possible between <literal>AccessExclusiveLocks</> arriving from
     the primary, cleanup WAL records that require buffer cleanup locks, and
     user requests that are waiting behind replayed <literal>AccessExclusiveLocks</>. Deadlocks
-    are resolved by time-out when they exceed <varname>max_standby_delay</>.
+    are resolved immediately, should they occur, though they are thought to be
+    rare in practice.
    </para>
 
    <para>
@@ -1516,8 +1516,9 @@ LOG:  database system is ready to accept read only connections
 </programlisting>
 
     Consistency information is recorded once per checkpoint on the primary, as long
-    as <varname>recovery_connections</> is enabled on the primary. If this parameter
-    is disabled, it is not possible to enable recovery connections on the standby.
+    as <varname>recovery_connections</> is enabled on the primary.  It is not possible
+    to enable recovery connections on the standby when reading WAL written during the
+    period that <varname>recovery_connections</> was disabled on the primary.
     Reaching a consistent state can also be delayed in the presence
     of both of these conditions: