On Sat, Mar 4, 2017 at 1:09 PM, Peter Eisentraut <peter.eisentr...@2ndquadrant.com> wrote: > On 2/27/17 00:32, Michael Paquier wrote: >> On Sun, Feb 26, 2017 at 8:24 AM, Michael Paquier >> <michael.paqu...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
