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: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
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-06-30 12:03:52
Message-ID: 39fd1199-f869-73de-c001-033db92f9fdf@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2022-06-30 12:48:32 pg_checkpointer is not a verb or verb phrase
Previous Message Yugo NAGATA 2022-06-30 10:38:48 Support TRUNCATE triggers on foreign tables