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.

diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index c89edd371415f2a6d7e19eb214ac191b42e761da..078d35c8f88da85fff56c2baa6e5bd200de685ef 100644 (file)
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -1,4 +1,4 @@
-
+
 
 
   Server Configuration
@@ -1862,18 +1862,31 @@ archive_command = 'copy "%p" "C:\\server\\archivedir\\%f"'  # Windows
       
        
         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 . 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 .
+        Typically, this parameter is used only during replication.
+        The default is 30 seconds.
         This parameter can only be set in the postgresql.conf
         file or on the server command line.
        
+       
+        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.
+      
+      
+       While it is tempting to believe that 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 max_standby_delay
+       before query cancellation is possible.
+