Re: [HACKERS] Automatic cleanup of oldest WAL segments with pg_receivexlog
От | Michael Paquier |
---|---|
Тема | Re: [HACKERS] Automatic cleanup of oldest WAL segments with pg_receivexlog |
Дата | |
Msg-id | CAB7nPqRFCM4pizCBUB_6_ctoLWx+KCMyUcCPfY49fyZnegzb+w@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Automatic cleanup of oldest WAL segments withpg_receivexlog (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>) |
Ответы |
Re: [HACKERS] Automatic cleanup of oldest WAL segments withpg_receivexlog
|
Список | pgsql-hackers |
On Sat, Mar 4, 2017 at 1:09 PM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote: > On 2/27/17 00:32, Michael Paquier wrote: >> On Sun, Feb 26, 2017 at 8:24 AM, Michael Paquier >> <michael.paquier@gmail.com> wrote: >>> To be consistent with archive_command and restore_command I'd rather >>> not do that. The command called can decide by itself what to do by >>> looking at the shape of the argument string. >> Just before the CF begins, I have taken some time to build up a patch >> that implements this --end-segment-command, with %f as placeholder. > > I think this repeats all the mistakes of archive_command, which > ironically pg_receivexlog was intended to fix, such as: shell commands > not fully portable, improper fsync support, poor error handling, lack of > integration with synchronous replication, inability to handle multiple > actions properly. Well, that's one reason why I was thinking that having an independent in-core option to clean up the tail of the oldest segments is interesting: users don't need to maintain their own infra logic to do anything. Now this end-segment command can as well be used with a small binary doing this cleanup, but the monitoring of the thing gets harder as multiple processes get spawned. -- Michael
В списке pgsql-hackers по дате отправления: