On Tue, Jan 22, 2013 at 8:33 AM, Dimitri Fontaine <dimi...@2ndquadrant.fr> wrote: > Heikki Linnakangas <hlinnakan...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers