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)

From: David Steele <david(at)pgmasters(dot)net>
To: Stephen Frost <sfrost(at)snowman(dot)net>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, SATYANARAYANA NARLAPURAM <satyanarlapuram(at)gmail(dot)com>, Euler Taveira <euler(at)eulerto(dot)com>
Subject: 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)
Date: 2022-05-03 21:47:21
Message-ID: 86b9106d-46dd-d66e-2408-9166f827a871@pgmasters.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 5/3/22 17:17, Stephen Frost wrote:
> * Bharath Rupireddy (bharath(dot)rupireddyforpostgres(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jacob Champion 2022-05-03 23:05:30 Re: [PATCH] Log details for client certificate failures
Previous Message Zheng Li 2022-05-03 21:30:20 Re: Support logical replication of DDLs