Skip site navigation (1) Skip section navigation (2)

Re: Core team statement on replication in PostgreSQL

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: Core team statement on replication in PostgreSQL
Date: 2008-05-30 08:29:17
Message-ID: 1212136157.4120.5.camel@ebony.site (view raw or flat)
Thread:
Lists: pgsql-advocacypgsql-hackers
On Thu, 2008-05-29 at 10:12 -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.)
> 
> Again, this will not replace Slony, pgPool, Continuent, Londiste, or
> other systems for many users, as it will be not be highly scalable nor
> support long-distance replication nor replicating less than an entire
> installation.  But it is time to include a simple, reliable basic
> replication feature in the core system.

I'm in full support of this and commend the work of the NTT team.

The goals and timescales are realistic and setting a timetable in this
way will help planning for many users,

I'm expecting to lead the charge on the Hot Standby project. The problem
mentioned is just one of the issues, though overall I'm now optimistic
about our eventual success in that area. I'm discussing this now with a
couple of sponsors and would welcome serious financial commitments to
this goal. Please contact me off-list if you agree also.

-- 
 Simon Riggs           www.2ndQuadrant.com
 PostgreSQL Training, Services and Support


In response to

pgsql-hackers by date

Next:From: Dimitri FontaineDate: 2008-05-30 08:29:30
Subject: Re: Core team statement on replication in PostgreSQL
Previous:From: Csaba NagyDate: 2008-05-30 08:19:56
Subject: Fwd: Re: Core team statement on replication in PostgreSQL

pgsql-advocacy by date

Next:From: Dimitri FontaineDate: 2008-05-30 08:29:30
Subject: Re: Core team statement on replication in PostgreSQL
Previous:From: Gurjeet SinghDate: 2008-05-30 07:01:46
Subject: Re: Core team statement on replication in PostgreSQL

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group