Re: pg_retainxlog for inclusion in 9.3?

From: Phil Sorber <phil(at)omniti(dot)com>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_retainxlog for inclusion in 9.3?
Date: 2013-01-05 18:34:02
Message-ID: CADAkt-gc=7BW-whbfqr=a8R5J0GBXsAH3tGRvXLmQF3ZP2T0-Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Jan 1, 2013 at 10:10 AM, Magnus Hagander <magnus(at)hagander(dot)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)
>
> --
> Magnus Hagander
> Me: http://www.hagander.net/
> Work: http://www.redpill-linpro.com/
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

+1 to this concept, however it may be implemented.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-01-05 19:15:30 Re: Re: [COMMITTERS] pgsql: Invent a "one-shot" variant of CachedPlans for better performanc
Previous Message Josh Kupershmidt 2013-01-05 18:21:49 Re: bad examples in pg_dump README