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.
This commit is contained in:
Bruce Momjian 2010-03-02 21:18:59 +00:00
parent 9393bc62c5
commit b098dbec0d
2 changed files with 7 additions and 4 deletions

View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.256 2010/02/27 14:46:05 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.257 2010/03/02 21:18:59 momjian Exp $ -->
<chapter Id="runtime-config">
<title>Server Configuration</title>
@ -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 <filename>postgresql.conf</>
file or on the server command line.
</para>

View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.52 2010/02/27 09:29:20 heikki Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.53 2010/03/02 21:18:59 momjian Exp $ -->
<chapter id="high-availability">
<title>High Availability, Load Balancing, and Replication</title>
@ -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. <varname>max_standby_delay</> should
not be used in this case because delayed WAL files might already
contain entries that invalidate the current shapshot.
</para>
<para>