On 2020-10-12 23:54, David G. Johnston wrote:
--- a/doc/src/sgml/backup.sgml
+++ b/doc/src/sgml/backup.sgml
@@ -722,6 +722,8 @@ test ! -f
/mnt/server/archivedir/00000001000000A900000065 && cp pg_wal/0
short <varname>archive_timeout</varname> — it will bloat
your archive
storage. <varname>archive_timeout</varname> settings of a minute
or so are
usually reasonable.
+ This is mitigated by the fact that empty WAL segments will not be
archived
+ even if the archive_timeout period has elapsed.
</para>
This is hopefully not what happens. What this would mean is that I'd
then have a sequence of WAL files named, say,
1, 2, 3, 7, 8, ...
because a few in the middle were not archived because they were empty.
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -3131,6 +3131,8 @@ include_dir 'conf.d'
<listitem>
<para>
Maximum time between automatic WAL checkpoints.
+ The automatic checkpoint will do nothing if no new WAL has been
+ written since the last recorded checkpoint.
If this value is specified without units, it is taken as seconds.
The valid range is between 30 seconds and one day.
The default is five minutes (<literal>5min</literal>).
I think what happens is that the checkpoint is skipped, not that the
checkpoint happens but does nothing. That is the wording you cited in
the other thread from
<https://www.postgresql.org/docs/13/wal-configuration.html>.
