At Thu, 2 Sep 2021 08:21:37 +0200, <o.lepretre@gmail.com> wrote in
> Hy Kyotaro,
>
> Thanks for this explanation. I joined the files to be complete.
Thanks, it is informative. It looks like this if sorted in the file-name order.
01/09/2021 12:15 16 777 216 000000010000008E00000061.deleted
01/09/2021 16:35 16 777 216 000000010000008E00000086.deleted
01/09/2021 16:35 16 777 216 000000010000008E00000087
30/08/2021 20:40 16 777 216 000000010000008E00000088
...
31/08/2021 17:58 16 777 216 000000010000008E000000CF
> If you looked the files only in timestamp order, with a high odds, the
> "oldest" file is a recycled file to be used in future, and the "newest" file
> is the currently written one. If so, the reason that the
> oldest-in-timestamp file is still there is it is still waiting to be used.
> Even if you removed the to-be-used-in-future files, such files would
> increase to the same extent according to the setting of min_wal_size.
The reason that 000000010000008E00000088 is still there is it is still
waiting to be used. The files 000000010000008E00000061/86.deleted
have been already removed in the postgres' view but remain because
someone else is still using it. If they persist too long, they could
be removed manually if possible.
The files 88 to CF look like preallocated, or recycled files. Since
there are 76 files, it seems like min_wal_size is set to 1GB or so. If
you don't need that many files preallocated in your pg_wal directory,
consider reducing min_wal_size. But note that the preallocated files
won't be gone right away just by doing that,
If you really want to delete that file right away, the preallocated
files are theoretically removable. You can see the current-writing
file name by the following query then move to somewhere the files with
names larger than the current file in the file-name order, then remove
the files after making sure the system can restart.
=# select pg_walfile_name(pg_current_wal_lsn());
If the system is active, the current file may advance so be careful
not to remove files with its substantial contents. This is why I said
"In any case, no WAL files ought to be manually removed."
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
