Hello,
> On 9 Nov 2023, at 01:30, Michael Paquier <michael@paquier.xyz> wrote:
>
> I am not really convinced that this is worth complicating the skipped
> path for this goal. In my experience, I've seen complaints where WAL
> archiving bloat was coming from the archive command not able to keep
> up with the amount generated by the backend, particularly because the
> command invocation was taking longer than it takes to generate a new
> segment. Even if there is a hole of activity in the server, if too
> much WAL has been generated it may not be enough to catch up depending
> on the number of segments that need to be processed. Others are free
> to chime in with extra opinions, of course.
I agree that there might multiple reasons of pg_wal bloat. Please note that
I am not addressing the WAL archiving issue at all. My proposal is to add a
small improvement to the WAL cleanup routine for WALs that have been already
archived successfully to free the disk space.
Yes, it might be not a common case, but a fairly realistic one. It occurred multiple times
in our production when we had temporary issues with archiving. This small
complication of the skipped path will help Postgres to return to a normal operational
state without any human operator / external control routine intervention.
> On 9 Nov 2023, at 01:30, Michael Paquier <michael@paquier.xyz> wrote:
>
> While on it, I think that your patch would cause incorrect and early
> removal of segments. It computes the name of the last segment to
> remove based on last_important_lsn, ignoring KeepLogSeg(), meaning
> that it ignores any WAL retention required by replication slots or
> wal_keep_size. And this causes the calculation of an incorrect segno
> horizon.
Please check the latest patch version, I believe that it has been already fixed there.
Thanks,
Daniil Zakhlystov
