Re: Core team statement on replication in PostgreSQL

Robert,

> 1.) Partial replication.
> 2.) WAN replication.
> 3.) Bi-directional replication.  (Yes, this is evil but there are 
> problems where it is indispensable.)
> 4.) Upgrade support.  Aside from database upgrade (how would this ever 
> really work between versions?), it would not support zero-downtime app 
> upgrades, which depend on bi-directional replication tricks.
> 5.) Heterogeneous replication.
> 6.) Finally, performance scaling using scale-out over large numbers of 
> replicas.  I think it’s possible to get tunnel vision on this—it’s not a 
> big requirement in the PG community because people don’t use PG in the 
> first place when they want to do this.  They use MySQL, which has very 
> good replication for performance scaling, though it’s rather weak for 
> availability.  

Let's not try to boil the ocean, hey?
From my perspective, the above use cases are what complex tools like 
Slony, Bucardo, Skytools, Continuent, pgCluster, pgPool2, etc., etc. are 
for.  Now, if you're saying that you want to develop row-based 
replication so that Continuent will work better, I'm all for it; but 
saying that we *shouldn't* implement the current spec which satisfies 
large numbers of users because it doesn't support *all* users is a 
recipe for self-defeat.  We can't satisfy all users with one 
implementation, and we shouldn't try.

I think, for that matter, that work on the common replication hooks 
supporting the external replication packages should continue.  We need 
these for precisely the reasons you state.  But ... single-master, 
single-slave, synch or asynch, whole-installation local network 
replication is a case which covers a *lot* of users' needs ... I'd argue 
the numerical majority.

--Josh