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