Question: We constantly bat this around the office, and the question continues to come up. How do you deal with PostgreSQL replication? I'm not even necessarily talking about advanced clusters, just keeping it simple with Master-Slave, Master-MultiSlave, and Master-Master. I find that setting it up for MySQL is typically pretty simple. Failover is straightforward if not perfect, especially for how easy it is to configure. We've played with Slony, but it's a bit too hands on (schema changes require intervention, new databases require intervention, etc). PGPool2 was pretty nice, until a node went down and we couldn't find a graceful way (other than bringing everything down and reseeding the fallen node) to get replication back in sync. Basically here's what I'm typically looking for:

* Easy setup (I'll settle for difficult setup, but easy to expand)
* Simplistic failover
* Bringing a fallen node back in just requires time (i.e. like mysql. Server goes down, you bring it up, and wait for replication to catch up)
* Schema changes don't break replication
* Adding a new database to the server is seamless (i.e. like mysql, you can replicate a whole DB server, so a new database is created on the master, it automatically propagates to the slave)

MySQL handles most of these fairly well, but I hold a certain fondness for PostgreSQL. Besides, we have some situations where it's our only option, and we'd like to add replication to the mix. What are you using currently, and how do you feel about your solution? This isn't a MySQL versus PostgreSQL post, I promise, because that's not what I'm trying to start. :)

Answer: 
And to throw another solution into the ring: rubyrep.

To compare with your requirements:

* Easy setup  

Yes, that's actually the primary focus of rubyrep.
* Simplistic failover  

Yes. In fact rubyrep does master-master replication - to fail over, no action is necessary at all. Just start using the other database.
* Schema changes don't break replication  

Yes.  

For non-primary key changes replication doesn't even have to stop (but make sure the schema is changes on both sides at the same time)  

To add / remove tables, simply restart the replication daemon.
Only changing the primary key column of a table takes a bit of effort.
* Adding a new database to the server is seamless (i.e. like mysql, you can replicate a whole DB server, so a new database is created on the master, it automatically propagates to the slave)  

This is only supported in a limited way: each rubyrep setup replicates only one database at a time. (But it is very easy to set up replication for more than one database.)
There really aren't any free / open-source ways to provide what you're looking for. If you want something that is so turn-key, look at various third-party commercial replication solutions.

Now, it *is* possible to sort of roll your own replication with Postgres using write-head log (WAL) shipping:

```
http://www.postgresql.org/docs/8.3/interactive/warm-standby.html

```

This is basically where you can put a secondary node into continuous recovery mode and import transaction logs into it every {small interval}. The Postgres configuration has "stubs" to allow you to do certain things when a Postgres when a WAL is completed and so no, and that's what that setup is predicated on -- utilising those "stubs." 

However, that doesn't allow you to do master-master and/or circular replication.

In any case, it definitely works for erdundancy, but I would not call it "easy setup," "simplistic failover," "seamless," or anything like that.