diff options
Diffstat (limited to 'doc/src')
| -rw-r--r-- | doc/src/sgml/catalogs.sgml | 2 | ||||
| -rw-r--r-- | doc/src/sgml/config.sgml | 21 | ||||
| -rw-r--r-- | doc/src/sgml/high-availability.sgml | 4 | ||||
| -rw-r--r-- | doc/src/sgml/ref/pg_basebackup.sgml | 2 | ||||
| -rw-r--r-- | doc/src/sgml/wal.sgml | 3 |
5 files changed, 17 insertions, 15 deletions
diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml index 9f00ea90e32..048ff284f76 100644 --- a/doc/src/sgml/catalogs.sgml +++ b/doc/src/sgml/catalogs.sgml @@ -11278,7 +11278,7 @@ SELECT * FROM pg_locks pl LEFT JOIN pg_prepared_xacts ppx <para><literal>extended</literal> means that <varname>max_wal_size</varname> is exceeded but the files are still retained, either by the replication slot or - by <varname>wal_keep_segments</varname>. + by <varname>wal_keep_size</varname>. </para> </listitem> <listitem> diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml index 1c491fb8ffc..ca6a3a523ff 100644 --- a/doc/src/sgml/config.sgml +++ b/doc/src/sgml/config.sgml @@ -3151,7 +3151,7 @@ include_dir 'conf.d' checkpoints. This is a soft limit; WAL size can exceed <varname>max_wal_size</varname> under special circumstances, such as heavy load, a failing <varname>archive_command</varname>, or a high - <varname>wal_keep_segments</varname> setting. + <varname>wal_keep_size</varname> setting. If this value is specified without units, it is taken as megabytes. The default is 1 GB. Increasing this parameter can increase the amount of time needed for @@ -3778,21 +3778,21 @@ restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Windows </listitem> </varlistentry> - <varlistentry id="guc-wal-keep-segments" xreflabel="wal_keep_segments"> - <term><varname>wal_keep_segments</varname> (<type>integer</type>) + <varlistentry id="guc-wal-keep-size" xreflabel="wal_keep_size"> + <term><varname>wal_keep_size</varname> (<type>integer</type>) <indexterm> - <primary><varname>wal_keep_segments</varname> configuration parameter</primary> + <primary><varname>wal_keep_size</varname> configuration parameter</primary> </indexterm> </term> <listitem> <para> - Specifies the minimum number of past log file segments kept in the + Specifies the minimum size of past log file segments kept in the <filename>pg_wal</filename> directory, in case a standby server needs to fetch them for streaming - replication. Each segment is normally 16 megabytes. If a standby + replication. If a standby server connected to the sending server falls behind by more than - <varname>wal_keep_segments</varname> segments, the sending server might remove - a WAL segment still needed by the standby, in which case the + <varname>wal_keep_size</varname> megabytes, the sending server might + remove a WAL segment still needed by the standby, in which case the replication connection will be terminated. Downstream connections will also eventually fail as a result. (However, the standby server can recover by fetching the segment from archive, if WAL @@ -3800,14 +3800,15 @@ restore_command = 'copy "C:\\server\\archivedir\\%f" "%p"' # Windows </para> <para> - This sets only the minimum number of segments retained in + This sets only the minimum size of segments retained in <filename>pg_wal</filename>; the system might need to retain more segments for WAL archival or to recover from a checkpoint. If - <varname>wal_keep_segments</varname> is zero (the default), the system + <varname>wal_keep_size</varname> is zero (the default), the system doesn't keep any extra segments for standby purposes, so 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. + If this value is specified without units, it is taken as megabytes. This parameter can only be set in the <filename>postgresql.conf</filename> file or on the server command line. </para> diff --git a/doc/src/sgml/high-availability.sgml b/doc/src/sgml/high-availability.sgml index 6a9184f314e..89f6d6eda63 100644 --- a/doc/src/sgml/high-availability.sgml +++ b/doc/src/sgml/high-availability.sgml @@ -785,7 +785,7 @@ archive_cleanup_command = 'pg_archivecleanup /path/to/archive %r' archiving, the server might recycle old WAL segments before the standby has received them. If this occurs, the standby will need to be reinitialized from a new base backup. You can avoid this by setting - <varname>wal_keep_segments</varname> to a value large enough to ensure that + <varname>wal_keep_size</varname> to a value large enough to ensure that WAL segments are not recycled too early, or by configuring a replication slot for the standby. If you set up a WAL archive that's accessible from the standby, these solutions are not required, since the standby can @@ -929,7 +929,7 @@ primary_conninfo = 'host=192.168.1.50 port=5432 user=foo password=foopass' </para> <para> In lieu of using replication slots, it is possible to prevent the removal - of old WAL segments using <xref linkend="guc-wal-keep-segments"/>, or by + of old WAL segments using <xref linkend="guc-wal-keep-size"/>, or by storing the segments in an archive using <xref linkend="guc-archive-command"/>. However, these methods often result in retaining more WAL segments than diff --git a/doc/src/sgml/ref/pg_basebackup.sgml b/doc/src/sgml/ref/pg_basebackup.sgml index aa41fb444fa..e246efbdb52 100644 --- a/doc/src/sgml/ref/pg_basebackup.sgml +++ b/doc/src/sgml/ref/pg_basebackup.sgml @@ -305,7 +305,7 @@ PostgreSQL documentation <para> The write-ahead log files are collected at the end of the backup. Therefore, it is necessary for the - <xref linkend="guc-wal-keep-segments"/> parameter to be set high + <xref linkend="guc-wal-keep-size"/> parameter to be set high enough that the log is not removed before the end of the backup. If the log has been rotated when it's time to transfer it, the backup will fail and be unusable. diff --git a/doc/src/sgml/wal.sgml b/doc/src/sgml/wal.sgml index 1902f36291d..7a13d8d5025 100644 --- a/doc/src/sgml/wal.sgml +++ b/doc/src/sgml/wal.sgml @@ -578,7 +578,8 @@ <para> Independently of <varname>max_wal_size</varname>, - <xref linkend="guc-wal-keep-segments"/> + 1 most recent WAL files are + the most recent <xref linkend="guc-wal-keep-size"/> megabytes of + WAL files plus one additional WAL file are kept at all times. Also, if WAL archiving is used, old segments can not be removed or recycled until they are archived. If WAL archiving cannot keep up with the pace that WAL is generated, or if <varname>archive_command</varname> |