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.

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to