On Mon, 5 Oct 2026 at 17:14, Joao Detomini <[email protected]> wrote: > > Hi, > > While looking at barman-wal-archive we ran into something that seems > to be missing in the server. If archiving breaks or can't keep up, > the unarchived WAL just piles up in pg_wal until the disk fills, and > max_slot_wal_keep_size doesn't help because it only covers > replication slots. We considered making the archive command drop WAL > once its queue gets too big, but then nothing tells the server, or > anyone else, that a segment was skipped on purpose, so PITR breaks > without a trace. Returning true from an archive_library for a segment > it didn't archive has the same problem, since the callback only knows > how to say "done" or "try again". > > What do people think about a setting like max_slot_wal_keep_size, but > for archiving? Off by default, and once it's exceeded the server > would let the oldest unarchived segments go and record that it did, > maybe in pg_stat_archiver, so tools can notice the gap and take a new > base backup. We haven't written anything yet and wanted to ask first > whether this is something you'd want in core.
WAL is generally archived to allow PITR through basebackup+WAL archive recovery. If we don't archive the WAL before dropping/reusing the segments, then we won't be able to replay that WAL for the PITR. I'm not sure such a feature (allowing removing WAL that is critical for PITR to work, if the backlog is large enough) is an acceptable solution: Doing so turns a guarantee (the RPO is defined by basebackup and WAL disk size, unarchived WAL can be recovered from the primary) into a best-effort approach (RPO is defined by basebackups: WAL can be lost permanently). All in all, I don't think this is a good idea. A PITR system with WAL archiving that is allowed to lose WAL should just ignore archiving the WAL by itself if it's too far behind; PG can't make that decision for it. Kind regards, Matthias van de Meent Databricks (https://www.databricks.com)
