On 5/3/22 17:17, Stephen Frost wrote:
* Bharath Rupireddy (bharath.rupireddyforpostg...@gmail.com) wrote:
The pg_walcleaner tool isn't intrusive in the sense that it doesn't
delete the WAL files that are required for the server to come up (as
it checks for the checkpoint redo WAL file), apart from this it has
archive_command too so no loss of the WAL file(s) at all unlike the
pgbackrest option.
Won't be any WAL loss with pgbackrest unless it's specifically
configured to throw it away- again, it's a tradeoff. Just suggesting
that we could have that be part of core as an option.
To be clear, pgBackRest never deletes WAL from the pg_wal directory (or
modifies that directory in any way). If archive-push-queue-max is
configured that simply means it will notify Postgres that WAL have been
archived if the max queue size has been exceeded (even though they have
not been archived).
This should never lead to WAL being required for crash recovery being
deleted unless there is a bug in Postgres.
But yeah, if they configure it there could be a loss of PITR capability.
Regards,
-David
