|
1 | | -<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.257 2010/03/0221:18:59 momjian Exp $ --> |
| 1 | +<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.258 2010/03/0223:38:17 momjian Exp $ --> |
2 | 2 |
|
3 | 3 | <chapter Id="runtime-config"> |
4 | 4 | <title>Server Configuration</title> |
@@ -1862,18 +1862,31 @@ archive_command = 'copy "%p" "C:\\server\\archivedir\\%f"' # Windows |
1862 | 1862 | <listitem> |
1863 | 1863 | <para> |
1864 | 1864 | When server acts as a standby, this parameter specifies a wait policy |
1865 | | - forqueriesthat conflict withdata changes being replayed by recovery. |
| 1865 | + forapplying WAL entriesthat conflict withactive queries. |
1866 | 1866 | If a conflict should occur the server will delay up to this number |
1867 | | - of seconds before it begins trying to resolve things less amicably, as |
1868 | | - described in <xref linkend="hot-standby-conflict">. Typically, |
1869 | | - this parameter makes sense only during replication, so when |
1870 | | - performing an archive recovery to recover from data loss a very high |
1871 | | - parameter setting or -1 which means wait forever is recommended. |
1872 | | - The default is 30 seconds. Increasing this parameter can delay |
1873 | | - master server changes from appearing on the standby. |
| 1867 | + of seconds before it cancels conflicting queries, as |
| 1868 | + described in <xref linkend="hot-standby-conflict">. |
| 1869 | + Typically, this parameter is used only during replication. |
| 1870 | + The default is 30 seconds. |
1874 | 1871 | This parameter can only be set in the <filename>postgresql.conf</> |
1875 | 1872 | file or on the server command line. |
1876 | 1873 | </para> |
| 1874 | + <para> |
| 1875 | + A high value makes query cancel less likely, and -1 |
| 1876 | + causes the standby to wait forever for a conflicting query to |
| 1877 | + complete. Increasing this parameter might delay master server |
| 1878 | + changes from appearing on the standby. |
| 1879 | + </para> |
| 1880 | + <para> |
| 1881 | + While it is tempting to believe that <varname>max_standby_delay</> |
| 1882 | + is the maximum number of seconds a query can run before |
| 1883 | + cancellation is possible, this is not true. When a long-running |
| 1884 | + query ends, there is a finite time required to apply backlogged |
| 1885 | + WAL logs. If a second long-running query appears before the |
| 1886 | + WAL has caught up, the snapshot taken by the second query will |
| 1887 | + allow significantly less than <varname>max_standby_delay</> |
| 1888 | + before query cancellation is possible. |
| 1889 | + </para> |
1877 | 1890 | </listitem> |
1878 | 1891 | </varlistentry> |
1879 | 1892 |
|
|