mirrors/postgres
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Adjust max_standby_delay documentation to be clearer, and mention that

Browse Source 
two adjacent long-running queries have much less than max_standby_delay
before query cancel is possible.
This commit is contained in:
Bruce Momjian 2010-03-02 23:38:17 +00:00
parent 05028cc33f
commit 7c55be792b
1 changed files with 22 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

31
doc/src/sgml/config.sgml
View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.257 2010/03/02 21:18:59 momjian Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.258 2010/03/02 23:38:17 momjian Exp $ -->
<chapter Id="runtime-config">
<title>Server Configuration</title>
@ -1862,18 +1862,31 @@ archive_command = 'copy "%p" "C:\\server\\archivedir\\%f"' # Windows
<listitem>
<para>
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 <xref linkend="hot-standby-conflict">. 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 <xref linkend="hot-standby-conflict">.
Typically, this parameter is used only during replication.
The default is 30 seconds.
This parameter can only be set in the <filename>postgresql.conf</>
file or on the server command line.
</para>
<para>
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.
</para>
<para>
While it is tempting to believe that <varname>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 <varname>max_standby_delay</>
before query cancellation is possible.
</para>
</listitem>
</varlistentry>