On Tue, Jan 22, 2013 at 8:33 AM, Dimitri Fontaine
<dimitri@2ndquadrant.fr> wrote:
> Heikki Linnakangas <hlinnakangas@vmware.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
> http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support