diff options
Diffstat (limited to 'doc/src/sgml/config.sgml')
| -rw-r--r-- | doc/src/sgml/config.sgml | 111 |
1 files changed, 73 insertions, 38 deletions
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index 412e535a48..391e4365c0 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -1,4 +1,4 @@ -<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.288 2010/06/30 02:43:10 momjian Exp $ --> +<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.289 2010/07/03 20:43:57 tgl Exp $ --> <chapter Id="runtime-config"> <title>Server Configuration</title> @@ -1841,6 +1841,8 @@ SET ENABLE_SEQSCAN TO OFF; <para> These settings control the behavior of the built-in <firstterm>streaming replication</> feature. + These parameters would be set on the primary server that is + to send replication data to one or more standby servers. </para> <variablelist> @@ -1866,7 +1868,7 @@ SET ENABLE_SEQSCAN TO OFF; </indexterm> <listitem> <para> - Specifies the delay between activity rounds for the WAL sender. + Specifies the delay between activity rounds for WAL sender processes. In each round the WAL sender sends any WAL accumulated since the last round to the standby server. It then sleeps for <varname>wal_sender_delay</> milliseconds, and repeats. The default @@ -1887,34 +1889,42 @@ SET ENABLE_SEQSCAN TO OFF; </indexterm> <listitem> <para> - Specifies the number of past log file segments kept in the + Specifies the minimum number of past log file segments kept in the <filename>pg_xlog</> directory, in case a standby server needs to fetch them for streaming replication. Each segment is normally 16 megabytes. If a standby server connected to the primary falls behind by more than <varname>wal_keep_segments</> segments, the primary might remove a WAL segment still needed by the standby, in which case the - replication connection will be terminated. + replication connection will be terminated. (However, the standby + server can recover by fetching the segment from archive, if WAL + archiving is in use.) </para> <para> - This sets only the minimum number of segments retained for standby - purposes; the system might need to retain more segments for WAL - archival or to recover from a checkpoint. If <varname>wal_keep_segments</> - is zero (the default), the system doesn't keep any extra segments - for standby purposes, and the number of old WAL segments available - for standbys is determined based only on the location of the previous - checkpoint and status of WAL archiving. - This parameter can only be set in the <filename>postgresql.conf</> - file or on the server command line. + This sets only the minimum number of segments retained in + <filename>pg_xlog</>; the system might need to retain more segments + for WAL archival or to recover from a checkpoint. If + <varname>wal_keep_segments</> is zero (the default), the system + doesn't keep any extra segments for standby purposes, and the number + of old WAL segments available to standby servers is a function of + the location of the previous checkpoint and status of WAL + archiving. This parameter can only be set in the + <filename>postgresql.conf</> file or on the server command line. </para> </listitem> </varlistentry> </variablelist> </sect2> + <sect2 id="runtime-config-standby"> <title>Standby Servers</title> + <para> + These settings control the behavior of a standby server that is + to receive replication data. + </para> + <variablelist> <varlistentry id="guc-hot-standby" xreflabel="hot_standby"> @@ -1933,39 +1943,64 @@ SET ENABLE_SEQSCAN TO OFF; </listitem> </varlistentry> - <varlistentry id="guc-max-standby-delay" xreflabel="max_standby_delay"> - <term><varname>max_standby_delay</varname> (<type>integer</type>)</term> + <varlistentry id="guc-max-standby-archive-delay" xreflabel="max_standby_archive_delay"> + <term><varname>max_standby_archive_delay</varname> (<type>integer</type>)</term> <indexterm> - <primary><varname>max_standby_delay</> configuration parameter</primary> + <primary><varname>max_standby_archive_delay</> configuration parameter</primary> </indexterm> <listitem> <para> - When Hot Standby is active, this parameter specifies a wait policy - for applying WAL entries that conflict with active queries. - If a conflict should occur the server will delay up to this long - before it cancels conflicting queries, as - described in <xref linkend="hot-standby-conflict">. - The default is 30 seconds (30 s). Units are milliseconds. - A value of -1 causes the standby to wait forever for a conflicting - query to complete. + When Hot Standby is active, this parameter determines how long the + standby server should wait before canceling standby queries that + conflict with about-to-be-applied WAL entries, as described in + <xref linkend="hot-standby-conflict">. + <varname>max_standby_archive_delay</> applies when WAL data is + being read from WAL archive (and is therefore not current). + The default is 30 seconds. Units are milliseconds if not specified. + A value of -1 allows the standby to wait forever for conflicting + queries to complete. 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. - Increasing this parameter or setting it to -1 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 length of time 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</> seconds - before query cancellation is possible. - </para> + Note that <varname>max_standby_archive_delay</> is not the same as the + maximum length of time a query can run before cancellation; rather it + is the maximum total time allowed to apply any one WAL segment's data. + Thus, if one query has resulted in significant delay earlier in the + WAL segment, subsequent conflicting queries will have much less grace + time. + </para> + </listitem> + </varlistentry> + + <varlistentry id="guc-max-standby-streaming-delay" xreflabel="max_standby_streaming_delay"> + <term><varname>max_standby_streaming_delay</varname> (<type>integer</type>)</term> + <indexterm> + <primary><varname>max_standby_streaming_delay</> configuration parameter</primary> + </indexterm> + <listitem> + <para> + When Hot Standby is active, this parameter determines how long the + standby server should wait before canceling standby queries that + conflict with about-to-be-applied WAL entries, as described in + <xref linkend="hot-standby-conflict">. + <varname>max_standby_streaming_delay</> applies when WAL data is + being received via streaming replication. + The default is 30 seconds. Units are milliseconds if not specified. + A value of -1 allows the standby to wait forever for conflicting + queries to complete. + This parameter can only be set in the <filename>postgresql.conf</> + file or on the server command line. + </para> + <para> + Note that <varname>max_standby_streaming_delay</> is not the same as + the maximum length of time a query can run before cancellation; rather + it is the maximum total time allowed to apply WAL data once it has + been received from the primary server. Thus, if one query has + resulted in significant delay, subsequent conflicting queries will + have much less grace time until the standby server has caught up + again. + </para> </listitem> </varlistentry> |