I've never delved into this domain before, but why is it that it is so hard to create multi-master replication for Postgres? We were considering it at work, and it seems the only solutions that provide that are unmaintained third party scripts written in Perl/Ruby, etc. MySQL has the NDB cluster solution, but that is way too restrictive as everything must be kept in memory.
It's hard because of the consistency guarantees that PostgreSQL makes. If you need true multi-master replication (you probably don't) the best solution is to use some form of queue to manage writes across the cluster. The DRBD solutions sound awesome but trade one SPOF for another, and have drawbacks in terms of speed (replicating block devices makes them slow) and risk (network latency, write contention) and are limited to at most two masters.
If you find yourself needing a replication solution beyond hot standby; it's possible that PostgreSQL isn't the right tool for the job.
Bucardo provides multi-master replication for PostgreSQL http://bucardo.org/ and is actively maintained, albiet written in Perl.
The reason most replication systems sit outside of PostgreSQL are there are many different use cases for replication and no one method is going to get it right enough to complicate the core code. There are efforts underway to create a common structure to base replication on so that projects like Bucardo, Slony and Londiste can more easily and reliably plug into the core database engine for replication.
NDB cluster is not something I'd recommend to anyone. At least it wasn't 2 years ago. I got random failures that only people at #mysql-ndb on freenode could explain, very cryptic log files, weird configuration bugs reproduced by tens of people and not fixed for years, etc.
It's even harder to maintain than multi-master. You know what can fail in multi-master and how to check it - 99% of cases is just one of the nodes stopping accepting the replication stream for some reason. You can check that easily, because you see secs_behind > 0 on the slave status - everything else ends up in the error log.
With NDB, the situation is much harder. You've got 3 types of nodes that can fail, you don't easily see if one of them failed (I had situations where every node was "connected", both data nodes were "live", but the manager (or was it frontend...) decided they're out of sync and cannot deal with them at all). Effectively you've got a network of independent nodes which can fail and not output any error - it's another node that shows you only the effect of such failure. I could not find any way to reliably monitor the cluster status and there are not nearly enough information on the web to solve the problems on your own. #mysql-ndb is great, but the people there can give you a patch to your database "to try if it fixes the problem" - problem that cannot be easily reproduced and causes the DB to stop working under a high load in the middle of the day - exactly when I need to DB to stay up.
Wow, thanks for all the replies. What I'm primarily interested in is eliminating single points of failure. So a number of web servers can bounce between any of the (geographically separated) database servers for read and write queries. I'm wondering if this is possible in a clean way with some general solution or if application code has to support partitioning of data to make this work.
For people without scaling/HA needs, the new permissions enhancements are a god-send for DBAs. PostgreSQL has very granular permissions, and it used to be impossible to grant default permissions within a database, as one can in MySQL. This can be very frustrating in multi-user environments.
Streaming Replication: http://www.postgresql.org/docs/9.0/static/warm-standby.html#...
Hot Standby: http://www.postgresql.org/docs/9.0/static/hot-standby.html