From b098dbec0d068a2aa13effb11fe1e07fb1fcf5eb Mon Sep 17 00:00:00 2001 From: Bruce Momjian Date: Tue, 2 Mar 2010 21:18:59 +0000 Subject: [PATCH] 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. --- doc/src/sgml/config.sgml | 5 +++-- doc/src/sgml/high-availability.sgml | 6 ++++-- 2 files changed, 7 insertions(+), 4 deletions(-) diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index 880d1c3052..c89edd3714 100644 --- 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 dc42d22f3a..ddad438b15 100644 --- 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.