Re: pg_walcleaner - new tool to detect, archive and delete the unneeded wal files (was Re: pg_archivecleanup - add the ability to detect, archive and delete the unneeded wal files on the primary) - Mailing list pgsql-hackers

On Thu, Jun 30, 2022 at 5:33 PM Peter Eisentraut
<peter.eisentraut@enterprisedb.com> wrote:
>
> On 25.04.22 20:39, Stephen Frost wrote:
> > All of which isn't an issue if we don't have an external tool trying to
> > do this and instead have the server doing it as the server knows its
> > internal status, that the archive command has been failing long enough
> > to pass the configuration threshold, and that the WAL isn't needed for
> > crash recovery.  The ability to avoid having to crash and go through
> > that process is pretty valuable.  Still, a crash may still happen and
> > it'd be useful to have a clean way to deal with it.  I'm not really a
> > fan of having to essentially configure this external command as well as
> > have the server configured.  Have we settled that there's no way to make
> > the server archive while there's no space available and before trying to
> > write out more data?
>
> I would also be in favor of not having an external command and instead
> pursue a solution built into the server along the ways you have
> outlined.  Besides the better integration and less potential for misuse
> that can be achieved that way, maintaining a separate tool has some
> constant overhead and if users only use it every ten years on average,
> it seems not worth it.

Thanks for the feedback. My understanding is this: introduce a GUC
(similar to max_slot_wal_keep_size), when set, beyond which postgres
will not keep the WAL files even if archiving is failing, am I right?

If my understanding is correct, are we going to say that postgres may
not archive "all" the WAL files that may be needed for PITR if the
archiving is failing for long enough? Will this be okay in production
environments?

Regards,
Bharath Rupireddy.