On 01/01/2013 04:10 PM, Magnus Hagander 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.
+1
------------------------
Hannu Krosing
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
