@@ -1844,9 +1844,9 @@ SET ENABLE_SEQSCAN TO OFF;
18441844 <varname>archive_mode</> and <varname>archive_command</> are
18451845 separate variables so that <varname>archive_command</> can be
18461846 changed without leaving archiving mode.
1847- This parameter can only be set at server start. <varname>wal_level</>
1848- must be set to <literal>archive </> or <literal>hot_standby</> to
1849- enable <varname>archive_mode </>.
1847+ This parameter can only be set at server start.
1848+ <varname>archive_mode </> cannot be enabled when
1849+ <varname>wal_level</> is set to <literal>minimal </>.
18501850 </para>
18511851 </listitem>
18521852 </varlistentry>
@@ -1911,7 +1911,10 @@ SET ENABLE_SEQSCAN TO OFF;
19111911 files. Therefore, it is unwise to use a very short
19121912 <varname>archive_timeout</> — it will bloat your archive
19131913 storage. <varname>archive_timeout</> settings of a minute or so are
1914- usually reasonable. This parameter can only be set in the
1914+ usually reasonable. You should consider using streaming replication,
1915+ instead of archiving, if you want data to be copied off the master
1916+ server more quickly than that.
1917+ This parameter can only be set in the
19151918 <filename>postgresql.conf</> file or on the server command line.
19161919 </para>
19171920 </listitem>
@@ -1920,14 +1923,32 @@ SET ENABLE_SEQSCAN TO OFF;
19201923 </variablelist>
19211924 </sect2>
19221925
1923- <sect2 id="runtime-config-replication">
1924- <title>Streaming Replication</title>
1926+ </sect1>
1927+
1928+ <sect1 id="runtime-config-replication">
1929+ <title>Replication</title>
1930+
1931+ <para>
1932+ These settings control the behavior of the built-in
1933+ <firstterm>streaming replication</> feature (see
1934+ <xref linkend="streaming-replication">).
1935+ Some parameters must be set on the master server, while others must be
1936+ set on the standby server(s) that will receive replication data.
1937+ </para>
1938+
1939+ <sect2 id="runtime-config-replication-master">
1940+ <title>Master Server</title>
19251941
19261942 <para>
1927- These settings control the behavior of the built-in
1928- <firstterm>streaming replication</> feature.
1929- These parameters would be set on the primary server that is
1943+ These parameters can be set on the primary server that is
19301944 to send replication data to one or more standby servers.
1945+ Note that in addition to these parameters,
1946+ <xref linkend="guc-wal-level"> must be set appropriately on the master
1947+ server, and you will typically want to enable WAL archiving as
1948+ well (see <xref linkend="runtime-config-wal-archiving">).
1949+ The values of these parameters on standby servers are irrelevant,
1950+ although you may wish to set them there in preparation for the
1951+ possibility of a standby becoming the master.
19311952 </para>
19321953
19331954 <variablelist>
@@ -1995,7 +2016,7 @@ SET ENABLE_SEQSCAN TO OFF;
19952016 <filename>pg_xlog</>; the system might need to retain more segments
19962017 for WAL archival or to recover from a checkpoint. If
19972018 <varname>wal_keep_segments</> is zero (the default), the system
1998- doesn't keep any extra segments for standby purposes, and the number
2019+ doesn't keep any extra segments for standby purposes, so the number
19992020 of old WAL segments available to standby servers is a function of
20002021 the location of the previous checkpoint and status of WAL
20012022 archiving. This parameter has no effect on restartpoints.
@@ -2057,50 +2078,45 @@ SET ENABLE_SEQSCAN TO OFF;
20572078 </para>
20582079 </listitem>
20592080 </varlistentry>
2060- </variablelist>
2061- </sect2>
2062-
2063- <sect2 id="runtime-config-sync-rep">
2064- <title>Synchronous Replication</title>
2065-
2066- <para>
2067- These settings control the behavior of the built-in
2068- <firstterm>synchronous replication</> feature.
2069- These parameters would be set on the primary server that is
2070- to send replication data to one or more standby servers.
2071- </para>
20722081
2073- <variablelist>
20742082 <varlistentry id="guc-synchronous-standby-names" xreflabel="synchronous_standby_names">
20752083 <term><varname>synchronous_standby_names</varname> (<type>string</type>)</term>
20762084 <indexterm>
20772085 <primary><varname>synchronous_standby_names</> configuration parameter</primary>
20782086 </indexterm>
20792087 <listitem>
20802088 <para>
2081- Specifies a priority ordered list of standby names that can offer
2082- synchronous replication. At any one time there will be at most one
2083- synchronous standby that will wake sleeping users following commit.
2084- The synchronous standby will be the first named standby that is
2085- both currently connected and streaming in real-time to the standby
2086- (as shown by a state of <literal>STREAMING</literal>). Other standby servers
2087- with listed later will become potential synchronous standbys.
2088- If the current synchronous standby disconnects for whatever reason
2089- it will be replaced immediately with the next highest priority standby.
2089+ Specifies a comma-separated list of standby names that can support
2090+ <firstterm>synchronous replication</>, as described in
2091+ <xref linkend="synchronous-replication">.
2092+ At any one time there will be at most one active synchronous standby;
2093+ transactions waiting for commit will be allowed to proceed after
2094+ this standby server confirms receipt of their data.
2095+ The synchronous standby will be the first standby named in this list
2096+ that is both currently connected and streaming data in real-time
2097+ (as shown by a state of <literal>STREAMING</literal> in the
2098+ <link linkend="monitoring-stats-views-table">
2099+ <literal>pg_stat_replication</></link> view).
2100+ Other standby servers appearing later in this list represent potential
2101+ synchronous standbys.
2102+ If the current synchronous standby disconnects for whatever reason,
2103+ it will be replaced immediately with the next-highest-priority standby.
20902104 Specifying more than one standby name can allow very high availability.
20912105 </para>
20922106 <para>
2093- The standby name is currently taken as the <varname>application_name</> setting of the
2094- standby, as set in the <varname>primary_conninfo</> on the standby. Names are
2095- not enforced for uniqueness. In case of duplicates one of the standbys
2096- will be chosen to be the synchronous standby, though exactly which
2097- one is indeterminate.
2098- The special entry <literal>*</> matches any application_name, including
2099- the default application name of <literal>walreceiver</>.
2107+ The name of a standby server for this purpose is the
2108+ <varname>application_name</> setting of the standby, as set in the
2109+ <varname>primary_conninfo</> of the standby's walreceiver. There is
2110+ no mechanism to enforce uniqueness. In case of duplicates one of the
2111+ matching standbys will be chosen to be the synchronous standby, though
2112+ exactly which one is indeterminate.
2113+ The special entry <literal>*</> matches any
2114+ <varname>application_name</>, including the default application name
2115+ of <literal>walreceiver</>.
21002116 </para>
21012117 <para>
2102- If no synchronous standby names are specified, then synchronous
2103- replication is not enabled and transaction commit will never wait for
2118+ If no synchronous standby names are specified here , then synchronous
2119+ replication is not enabled and transaction commits will not wait for
21042120 replication. This is the default configuration. Even when
21052121 synchronous replication is enabled, individual transactions can be
21062122 configured not to wait for replication by setting the
@@ -2117,12 +2133,13 @@ SET ENABLE_SEQSCAN TO OFF;
21172133 </variablelist>
21182134 </sect2>
21192135
2120- <sect2 id="runtime-config-standby">
2121- <title>Standby Servers</title>
2136+ <sect2 id="runtime-config-replication- standby">
2137+ <title>Standby Servers</title>
21222138
21232139 <para>
21242140 These settings control the behavior of a standby server that is
2125- to receive replication data.
2141+ to receive replication data. Their values on the master server
2142+ are irrelevant.
21262143 </para>
21272144
21282145 <variablelist>
@@ -2213,12 +2230,14 @@ SET ENABLE_SEQSCAN TO OFF;
22132230 <para>
22142231 Specifies the minimum frequency for the WAL receiver
22152232 process on the standby to send information about replication progress
2216- to the primary, where they can be seen using the
2217- <literal>pg_stat_replication</literal> view. The standby will report
2233+ to the primary, where it can be seen using the
2234+ <link linkend="monitoring-stats-views-table">
2235+ <literal>pg_stat_replication</></link> view. The standby will report
22182236 the last transaction log position it has written, the last position it
2219- has flushed to disk, and the last position it has applied. The parameter
2237+ has flushed to disk, and the last position it has applied.
2238+ This parameter's
22202239 value is the maximum interval, in seconds, between reports. Updates are
2221- sent each time the write or flush positions changed , or at least as
2240+ sent each time the write or flush positions change , or at least as
22222241 often as specified by this parameter. Thus, the apply position may
22232242 lag slightly behind the true position. Setting this parameter to zero
22242243 disables status updates completely. This parameter can only be set in
0 commit comments