Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit b098dbe

Browse files
committed
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.
1 parent 9393bc6 commit b098dbe

File tree

2 files changed

+7
-4
lines changed

2 files changed

+7
-4
lines changed

doc/src/sgml/config.sgml

Lines changed: 3 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.256 2010/02/27 14:46:05 momjian Exp $ -->
1+
<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.257 2010/03/02 21:18:59 momjian Exp $ -->
22

33
<chapter Id="runtime-config">
44
<title>Server Configuration</title>
@@ -1869,7 +1869,8 @@ archive_command = 'copy "%p" "C:\\server\\archivedir\\%f"' # Windows
18691869
this parameter makes sense only during replication, so when
18701870
performing an archive recovery to recover from data loss a very high
18711871
parameter setting or -1 which means wait forever is recommended.
1872-
The default is 30 seconds.
1872+
The default is 30 seconds. Increasing this parameter can delay
1873+
master server changes from appearing on the standby.
18731874
This parameter can only be set in the <filename>postgresql.conf</>
18741875
file or on the server command line.
18751876
</para>

doc/src/sgml/high-availability.sgml

Lines changed: 4 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,4 +1,4 @@
1-
<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.52 2010/02/27 09:29:20 heikki Exp $ -->
1+
<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.53 2010/03/02 21:18:59 momjian Exp $ -->
22

33
<chapter id="high-availability">
44
<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'
14101410
that the primary and standby nodes are linked via the WAL, so the cleanup
14111411
situation is no different from the case where the query ran on the primary
14121412
node itself. And you are still getting the benefit of off-loading the
1413-
execution onto the standby.
1413+
execution onto the standby. <varname>max_standby_delay</> should
1414+
not be used in this case because delayed WAL files might already
1415+
contain entries that invalidate the current shapshot.
14141416
</para>
14151417

14161418
<para>

0 commit comments

Comments
 (0)