Skip site navigation (1) Skip section navigation (2)

Re: pg_retainxlog for inclusion in 9.3?

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: pg_retainxlog for inclusion in 9.3?
Date: 2013-01-03 16:32:19
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Thu, Jan 3, 2013 at 3:13 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> 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
>> 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

In response to


pgsql-hackers by date

Next:From: Greg StarkDate: 2013-01-03 16:38:49
Subject: Re: Proposal: Store "timestamptz" of database creation on "pg_database"
Previous:From: Alvaro HerreraDate: 2013-01-03 16:17:33
Subject: Re: Proposal: Store "timestamptz" of database creation on "pg_database"

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group