Josh Berkus <j...@agliodbs.com> writes: > Well, one thing to be addressed is separating the PITR functionality from > replication. PITR needs a lot of features -- timelines, recovery stop > points, etc. -- which replication doesn't need or want. I think that > focussing on streaming replication functionality and ignoring the archive > logs case is probably the best way to logically separate these two. > Presumably anyone who needs archive logs as well will be a professional DBA.
So, I've been thinking some more about this. We now have two modes of operation when starting up a PostgreSQL cluster, either it's a primary/master or it's a standby (in recovery or hot_standby). What I think would make sense here would be to add another mode of operation, archiving. A cluster that is archiving will accept replication connections and will accept WAL files streamed there, that it will put on its archive directory, defaults to $PGDATA/pg_xlog_archive. It should also be able to take a base backup from its primary server, maybe with a new pg_ctl command. The base backup location defaults to $PGDATA/pg_basebackup/$label. Then, it would also accept replication connection in the other way around, starting a walsender to publish its archive or its base backup, so that you could prepare a new standby against the archive server, then switch the primary_conninfo to the master and that's it. Now, the archive and restore commands in this setup would be internal commands pg_walsender and pg_walreceiver. That would mean we need to extend those spacial backends to be able to send and receive a full WAL file but it sounds simple enough, right? Then we could add support for those to compress the WAL files before streaming, as we're talking "internal commands" here it sounds easy enough (we're already linking against gzip I think). The base backup streaming support would be there for the archiving mode but also for the normal standby "empty $PGDATA" initial start up. Comments? -- 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
