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.
This addition assumes it is known that the archive process first fills the files to their maximum size and then archives them. That filling of the file is what causes the next file in the sequence to be created. So if the archiving doesn't happen the files do not get filled and the status-quo prevails.
If the above wants to be made more explicit in this change maybe:
"This is mitigated by the fact that archiving, and thus filling, the active WAL segment will not happen if that segment is empty; it will continue as the active segment."
> --- 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>).
