Re: Core team statement on replication in PostgreSQL - Mailing list pgsql-hackers

On Thu, May 29, 2008 at 10:12:55AM -0400, Tom Lane wrote:
> The Postgres core team met at PGCon to discuss a few issues, the
> largest of which is the need for simple, built-in replication for
> PostgreSQL.  Historically the project policy has been to avoid
> putting replication into core PostgreSQL, so as to leave room for
> development of competing solutions, recognizing that there is no
> "one size fits all" replication solution.  However, it is becoming
> clear that this policy is hindering acceptance of PostgreSQL to too
> great an extent, compared to the benefit it offers to the add-on
> replication projects.  Users who might consider PostgreSQL are
> choosing other database systems because our existing replication
> options are too complex to install and use for simple cases.  In
> practice, simple asynchronous single-master-multiple-slave
> replication covers a respectable fraction of use cases, so we have
> concluded that we should allow such a feature to be included in the
> core project.  We emphasize that this is not meant to prevent
> continued development of add-on replication projects that cover more
> complex use cases.
> 
> We believe that the most appropriate base technology for this is
> probably real-time WAL log shipping, as was demoed by NTT OSS at
> PGCon.  We hope that such a feature can be completed for 8.4.

> Ideally this would be coupled with the ability to execute read-only
> queries on the slave servers, but we see technical difficulties that
> might prevent that from being completed before 8.5 or even further
> out.  (The big problem is that long-running slave-side queries might
> still need tuples that are vacuumable on the master, and so
> replication of vacuuming actions would cause the slave's queries to
> deliver wrong answers.)

This part is a deal-killer.  It's a giant up-hill slog to sell warm
standby to those in charge of making resources available because the
warm standby machine consumes SA time, bandwidth, power, rack space,
etc., but provides no tangible benefit, and this feature would have
exactly the same problem.

IMHO, without the ability to do read-only queries on slaves, it's not
worth doing this feature at all.

Cheers,
David.
-- 
David Fetter <david@fetter.org> http://fetter.org/
Phone: +1 415 235 3778  AIM: dfetter666  Yahoo!: dfetter
Skype: davidfetter      XMPP: david.fetter@gmail.com

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate