From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Automatic cleanup of oldest WAL segments with pg_receivexlog |
Date: | 2017-02-25 23:24:04 |
Message-ID: | CAB7nPqRu+2psZNK7NE-h+5SiaGJtEO+gPxHNPp6cDJP_+av7AA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Feb 26, 2017 at 12:41 AM, Magnus Hagander <magnus(at)hagander(dot)net> wrote:
> On Feb 25, 2017 15:00, "Michael Paquier" <michael(dot)paquier(at)gmail(dot)com> wrote:
>
> On Sat, Feb 25, 2017 at 10:32 PM, Magnus Hagander <magnus(at)hagander(dot)net>
> wrote:
>> Oh, I definitely think such a command should be able to take a placeholder
>> like %f telling which segment it has just processed. In fact, I'd consider
>> it one of the most important features of it :)
>
> I cannot think about any other meaningful variables, do you?
>
>
> Not offhand. But one thing that could go to the question of parameter name -
> what if we finish something that's not a segment. During a time line switch
> for example, we also get other files don't we? We probably want to trigger
> at least some command in that case - either with an argument or by a
> different parameter?
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.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2017-02-25 23:49:01 | Re: bytea_output output of base64 |
Previous Message | Bruce Momjian | 2017-02-25 23:01:54 | Re: Documentation improvements for partitioning |