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)
От | Peter Eisentraut |
---|---|
Тема | 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) |
Дата | |
Msg-id | 39fd1199-f869-73de-c001-033db92f9fdf@enterprisedb.com обсуждение исходный текст |
Ответ на | 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) (Stephen Frost <sfrost@snowman.net>) |
Ответы |
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)
|
Список | 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.
В списке pgsql-hackers по дате отправления: