On Fri, Jan 4, 2013 at 7:13 PM, Peter Eisentraut <pete...@gmx.net> wrote: > On 1/3/13 12:30 PM, Robert Haas wrote: >> On Thu, Jan 3, 2013 at 11:32 AM, Magnus Hagander <mag...@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. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
