Adjust max_standby_delay documentation to be clearer, and mention that

two adjacent long-running queries have much less than max_standby_delay
before query cancel is possible.

doc/src/sgml/config.sgml

@@ -1,4 +1,4 @@
-<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.257 2010/03/02 21:18:59 momjian Exp $ -->
+<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.258 2010/03/02 23:38:17 momjian Exp $ -->
 
 <chapter Id="runtime-config">
   <title>Server Configuration</title>
@@ -1862,18 +1862,31 @@ archive_command = 'copy "%p" "C:\\server\\archivedir\\%f"'  # Windows
       <listitem>
        <para>
         When server acts as a standby, this parameter specifies a wait policy
-        for queries that conflict with data changes being replayed by recovery.
+        for applying WAL entries that conflict with active queries.
         If a conflict should occur the server will delay up to this number
-        of seconds before it begins trying to resolve things less amicably, as
-        described in <xref linkend="hot-standby-conflict">. Typically,
-        this parameter makes sense only during replication, so when
-        performing an archive recovery to recover from data loss a very high
-        parameter setting or -1 which means wait forever is recommended.
-        The default is 30 seconds.  Increasing this parameter can delay
-        master server changes from appearing on the standby.
+        of seconds before it cancels conflicting queries, as
+        described in <xref linkend="hot-standby-conflict">.
+        Typically, this parameter is used only during replication.
+        The default is 30 seconds.
         This parameter can only be set in the <filename>postgresql.conf</>
         file or on the server command line.
        </para>
+       <para>
+        A high value makes query cancel less likely, and -1
+        causes the standby to wait forever for a conflicting query to
+        complete.  Increasing this parameter might delay master server
+        changes from appearing on the standby.
+      </para>
+      <para>
+       While it is tempting to believe that <varname>max_standby_delay</>
+       is the maximum number of seconds a query can run before
+       cancellation is possible, this is not true.  When a long-running
+       query ends, there is a finite time required to apply backlogged
+       WAL logs.  If a second long-running query appears before the
+       WAL has caught up, the snapshot taken by the second query will
+       allow significantly less than <varname>max_standby_delay</>
+       before query cancellation is possible.
+      </para>
       </listitem>
      </varlistentry>