On Sat, Jan 5, 2013 at 3:11 PM, Magnus Hagander <magnus@hagander.net> wrote:
> On Fri, Jan 4, 2013 at 7:13 PM, Peter Eisentraut <peter_e@gmx.net> wrote:
>> On 1/3/13 12:30 PM, Robert Haas wrote:
>>> On Thu, Jan 3, 2013 at 11:32 AM, Magnus Hagander <magnus@hagander.net> wrote:
>>>> Any particular reason? It goes pretty tightly together with
>>>> pg_receivexlog, which is why I'd prefer putting it alongside that one.
>>>> But if you have a good argument against it, I can change my mind :)
>>>
>>> Mostly that it seems like a hack, and I suspect we may come up with a
>>> better way to do this in the future.
>>
>> It does seem like a hack. Couldn't this be implemented with a backend
>> switch instead?
>
> It definitely is a bit of a hack.
>
> I assume by backend switch you mean guc, right? If so, no, not easily
> so. Because it's the archiver process that does the deleting. And this
> process does not have access to a "full backend interface", e.g. the
> ability to run a query. We could make it look at the same data that's
> currently shown in pg_stat_replicatoin through shared memory, but thta
> would *only* work in the very most simple cases (e.g. a single
> pg_receivexlog and no other replication). The ability to run a custom
> SQL query is going to be necessary for anything a bit more advanced.
>
>
>> Also, as a small practical matter, since this is a server-side program
>> (since it's being used as archive_command), we shouldn't put it into the
>> pg_basebackup directory, because that would blur the lines about what to
>> install where, in particular for the translations.
>
> Good argument. That along with the being a hack, and the comment from
> Robert, means that maybe contrib/ is a better place for it, yes.
Here's a version for inclusion in /contrib.
--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/
