Document the effect of max_standby_delay on increasing the delay of data

from master to slave, and discourage its use during slave/master
keep-xid-alive connections.

diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 880d1c3052820fe4ff3b82f1969f91f625b2b64d..c89edd371415f2a6d7e19eb214ac191b42e761da 100644 (file)
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -1,4 +1,4 @@
-
+
 
 
   Server Configuration
@@ -1869,7 +1869,8 @@ archive_command = 'copy "%p" "C:\\server\\archivedir\\%f"'  # Windows
         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.
+        The default is 30 seconds.  Increasing this parameter can delay
+        master server changes from appearing on the standby.
         This parameter can only be set in the postgresql.conf
         file or on the server command line.
        

diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml
index dc42d22f3ab0ec9165e2ad4cb5093ed46cec1bf0..ddad438b15926dba67332cea37818c1ed6847f73 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
@@ -1410,7 +1410,9 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass'
     that the primary and standby nodes are linked via the WAL, so the cleanup
     situation is no different from the case where the query ran on the primary
     node itself.  And you are still getting the benefit of off-loading the
-    execution onto the standby.
+    execution onto the standby. max_standby_delay should
+    not be used in this case because delayed WAL files might already
+    contain entries that invalidate the current shapshot.