On Thu, Jan 3, 2013 at 3:13 PM, Robert Haas <robertmh...@gmail.com> wrote: > On Tue, Jan 1, 2013 at 10:10 AM, Magnus Hagander <mag...@hagander.net> wrote: >> So, it turns out the reason I got no feedback on this tool, was that I >> forgot both to email about and to actually push the code to github :O >> So this is actually code that's almost half a year old and that I was >> supposed to submit for the first or second commitfest. Oops. >> >> So, the tool and a README for it right now can be found at >> https://github.com/mhagander/pg_retainxlog for the time being. >> >> The idea behind the tool is to plug a hole in the case when >> pg_receivexlog is used for log archiving, which is that you still need >> a "blocking" archive_command in order to make sure that files aren't >> recycled on the master. So for 9.2 you can do this with an >> archive_command that checks if the file has appeared properly on the >> slave - but that usually means you're back at requiring ssh >> connectivity between the machines, for example. Even though this >> information is actually avialable on the master... >> >> This can also be of use to pure replication scenarios, where you don't >> know how to tune wal_keep_segments, but using actual live feedback >> instead of guessing. >> >> When pg_retainxlog is used as an archive_command, it will check the >> pg_stat_replication view instead of checking the slave. It will then >> only return ok once the requested logfile has been replicated to the >> slave. By default it will look for a replication client named >> pg_receivexlog, but it supports overriding the query with anything - >> so you can say things like "needs to have arrived on at least two >> replication slaves before we consider it archived". Or if used instead >> of wal_keep_segmnets, needs to have arrived at *all* replication >> slaves. >> >> Is this a tool that people would like to see included in the general >> toolchain? If so, I'll reformat it to work in the general build >> environment and submit it for the last commitfest. >> >> (comments on the code itself are of course also welcome) > > I would tend to vote for putting this in contrib rather than src/bin. > But apart from that I have no objection to the idea.
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 :) -- 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
