1
0
mirror of https://github.com/postgres/postgres.git synced 2025-06-16 06:01:02 +03:00

Rename wal_keep_segments to wal_keep_size.

max_slot_wal_keep_size that was added in v13 and wal_keep_segments are
the GUC parameters to specify how much WAL files to retain for
the standby servers. While max_slot_wal_keep_size accepts the number of
bytes of WAL files, wal_keep_segments accepts the number of WAL files.
This difference of setting units between those similar parameters could
be confusing to users.

To alleviate this situation, this commit renames wal_keep_segments to
wal_keep_size, and make users specify the WAL size in it instead of
the number of WAL files.

There was also the idea to rename max_slot_wal_keep_size to
max_slot_wal_keep_segments, in the discussion. But we have been moving
away from measuring in segments, for example, checkpoint_segments was
replaced by max_wal_size. So we concluded to rename wal_keep_segments
to wal_keep_size.

Back-patch to v13 where max_slot_wal_keep_size was added.

Author: Fujii Masao
Reviewed-by: Álvaro Herrera, Kyotaro Horiguchi, David Steele
Discussion: https://postgr.es/m/574b4ea3-e0f9-b175-ead2-ebea7faea855@oss.nttdata.com
This commit is contained in:
Fujii Masao
2020-07-20 13:30:18 +09:00
parent 0bead9af48
commit c3fe108c02
12 changed files with 58 additions and 48 deletions

View File

@ -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>

View File

@ -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>

View File

@ -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

View File

@ -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.

View File

@ -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>