Hi!
Thanks for your review.
> I am not sure to understand your last sentence here. Once the
> archiver is back up, you mean that the WAL segments that were not
> previously archived still are still not archived? Or do you mean that
> because of a succession of checkpoint skipped we are just enable to
> remove them from pg_wal.
Yes, the latter is correct - we are unable to clean up the already archived WALs
due to the checkpoint being skipped.
> I am not convinced that this is worth the addition in the skipped
> path. If your system is idle and a set of checkpoints is skipped, the
> data folder is not going to be under extra space pressure because of
> database activity (okay, unlogged tables even if these would generate
> some WAL for init pages), because there is nothing happening in it
> with no "important" WAL generated. Note that the backend is very
> unlikely going to generate WAL only marked with XLOG_MARK_UNIMPORTANT.
> More to the point: what's the origin of the disk space issues? System
> logs, unlogged tables or something else? It is usually a good
> practice to move logs to a different partition. At the end, it sounds
> to me that removing segments more aggressively is just kicking the can
> elsewhere, without taking care of the origin of the disk issues.
This problem arises when disk space issues are caused by temporary failed archiving.
As a result, the pg_wal becomes filled with WALs. This situation
leads to Postgres being unable to perform any write operations since there is no more
free disk space left. Usually, cloud providers switch the cluster to a Read-Only mode
if there is less than 3-4% of the available disk space left, but this also does not resolve
this problem.
The actual problem is that after archiving starts working normally again, Postgres is
unable to free the accumulated WAL and switch to Read-Write mode due to the
checkpoint being skipped, leading to a vicious circle. However, nothing prevents
Postgres from exiting such situations on its own. This patch addresses this specific
behavior, enabling Postgres to resolve such situations autonomously.
Thank you,
Daniil Zakhlystov
