Re: Simplifying replication - Mailing list pgsql-hackers

From Robert Treat
Subject Re: Simplifying replication
Date
Msg-id AANLkTiksJusKyg1=R2_jxeskSaXGQq2DvaYmzFzjGN0A@mail.gmail.com
Whole thread Raw
In response to Re: Simplifying replication  (Greg Smith <greg@2ndquadrant.com>)
List pgsql-hackers
On Tue, Oct 19, 2010 at 11:16 AM, Greg Smith <greg@2ndquadrant.com> wrote:
Josh Berkus wrote:
It is critical that we make replication easier to set up, administrate and monitor than it currently is.  In my conversations with people, this is more important to our users and the adoption of PostgreSQL than synchronous replication is.
 
<snip>
 
I find this launch into a new round of bike-shedding a bit distracting.  If you want this to be easier to use, which it's obvious to any observer it should be because what's delivered in 9.0 is way too complicated, please work on finding development resources to assign to that problem.  Because that's the bottleneck on simplifying things, not ideas about what to do.  I would recommend finding or assigning a developer to work on integrating base backup in to the streaming protocol as the biggest single thing that would improve the built-in replication.  All of the rest of the trivia about what knobs to set and such are tiny details that make for only a minor improvement until that's taken care of.


Yeah, I'm sure we all think it should be easier, but figuring out what that means is certainly a moving target. The idea of being able to create a base backup automagically sounds good, but comparatively it's not significantly more difficult than what many other systems make you do, and actually if done incorrectly could be something rather limiting. On the whole the customers we are talking with are far more concerned about things like managing failover scenarios when you have multiple slaves, and it's the lack of capabilities around those kinds of things that hurt postgres adoption much more than it being hard to set up. 


Robert Treat

pgsql-hackers by date:

Previous
From: Aidan Van Dyk
Date:
Subject: Re: pg_rawdump
Next
From: Tom Lane
Date:
Subject: Re: pg_rawdump