1
0
mirror of https://github.com/postgres/postgres.git synced 2025-07-28 23:42:10 +03:00

Rename standby_keep_segments to wal_keep_segments.

Also, make the name of the GUC and the name of the backing variable match.
Alnong the way, clean up a couple of slight typographical errors in the
related docs.
This commit is contained in:
Robert Haas
2010-04-20 11:15:06 +00:00
parent c670410e7f
commit 481cb5d9b5
6 changed files with 22 additions and 22 deletions

View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.268 2010/04/19 00:55:25 rhaas Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/config.sgml,v 1.269 2010/04/20 11:15:06 rhaas Exp $ -->
<chapter Id="runtime-config">
<title>Server Configuration</title>
@ -1842,10 +1842,10 @@ SET ENABLE_SEQSCAN TO OFF;
</listitem>
</varlistentry>
<varlistentry id="guc-standby-keep-segments" xreflabel="standby_keep_segments">
<term><varname>standby_keep_segments</varname> (<type>integer</type>)</term>
<varlistentry id="guc-wal-keep-segments" xreflabel="wal_keep_segments">
<term><varname>wal_keep_segments</varname> (<type>integer</type>)</term>
<indexterm>
<primary><varname>standby_keep_segments</> configuration parameter</primary>
<primary><varname>wal_keep_segments</> configuration parameter</primary>
</indexterm>
<listitem>
<para>
@ -1853,17 +1853,17 @@ SET ENABLE_SEQSCAN TO OFF;
directory, in case a standby server needs to fetch them via streaming
replication. Each segment is normally 16 megabytes. If a standby
server connected to the primary falls behind more than
<varname>standby_keep_segments</> segments, the primary might remove
<varname>wal_keep_segments</> segments, the primary might remove
a WAL segment still needed by the standby and the replication
connection will be terminated.
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>standby_keep_segments</>
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 archival.
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>

View File

@ -1,4 +1,4 @@
<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.60 2010/04/12 10:01:04 heikki Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/high-availability.sgml,v 1.61 2010/04/20 11:15:06 rhaas Exp $ -->
<chapter id="high-availability">
<title>High Availability, Load Balancing, and Replication</title>
@ -737,7 +737,7 @@ trigger_file = '/path/to/trigger_file'
falls behind too much, the primary will delete old WAL files still
needed by the standby, and the standby will have to be manually restored
from a base backup. You can control how long the primary retains old WAL
segments using the <varname>standby_keep_segments</> setting.
segments using the <varname>wal_keep_segments</> setting.
</para>
<para>