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

Re: Teaching pg_receivexlog to follow timeline switches

From: Phil Sorber <phil(at)omniti(dot)com>
To: Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Teaching pg_receivexlog to follow timeline switches
Date: 2013-01-22 14:13:51
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Tue, Jan 22, 2013 at 8:33 AM, Dimitri Fontaine
<dimitri(at)2ndquadrant(dot)fr> wrote:
> Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> writes:
>> You might not want to keep a copy of the whole data directory around, as you
>> have to in a cascading standby. I can see value in a separate WAL proxy
>> software, especially if it's integrated into a larger backup manager program
>> like barman or wal-e.
> +1
> I somehow forgot about $PGDATA here. Time for a little break I guess :)
> Another idea is to have a daemon mode pg_receivexlog where not only it
> can maintain a local archive but also feed it using the replication
> protocol to standbies, keeping track of their position.

I'm not sure if i described it well, but that's essentially what I was
asking about. It would have both wal receiving and and wal sending
capability. Along with it's own local WAL storage perhaps governed in
size by a keep_wal_segments and also a longer term archive that you
could have compressed but also pull from with a archive and restore
command. And also be able to act as a synchronous replication peer. I
think it has already been discussed to have pg_receivexlog do that
last one.

So yeah, a cascading standby without $PGDATA or hot_standby or large
shared_buffers resources. It seems like maybe we could add through
subtraction. Add a parameter that disables wal replay? I'm sure
there'd be more things it would have to disable, but then it's not two
separate binaries.

> Regards,
> --
> Dimitri Fontaine
>     PostgreSQL : Expertise, Formation et Support

In response to

pgsql-hackers by date

Next:From: Andrew DunstanDate: 2013-01-22 14:22:04
Subject: Re: CF3+4 (was Re: Parallel query execution)
Previous:From: Amit KapilaDate: 2013-01-22 14:07:55
Subject: Re: Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]

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