On Sat, Jan 5, 2013 at 3:11 PM, Magnus Hagander <mag...@hagander.net> wrote: > 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.
Here's a version for inclusion in /contrib. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/
pg_retainxlog.diff
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
