Message-ID: <4CBDBDDE.20605@agliodbs.com>
Date: Tue, 19 Oct 2010 08:48:46 -0700
From: Josh Berkus <josh@agliodbs.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.1.9pre) Gecko/20100217 Shredder/3.0.3pre
MIME-Version: 1.0
To: Greg Smith <greg@2ndquadrant.com>
CC: postgres hackers <pgsql-hackers@postgresql.org>
Subject: Re: Simplifying replication
References: <4CBCE356.2080703@agliodbs.com> <4CBDB665.60408@2ndquadrant.com>
In-Reply-To: <4CBDB665.60408@2ndquadrant.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit


> You should enjoy one of the patches we're furiously working on then,
> which is aiming at some of the administration and monitoring pieces
> here.

Great, glad to hear it!  Would you be willing to go into detail?

> I have my own grand vision of how easy replication should be to
> setup too.

So, share it.  I'd look forward to hearing it, especially since your 
vision probably takes synch rep and quorum commit into account, which 
mine doesn't.   If not here, then on your blog.

> Visions and plans are nice, but building functional pieces of
> them and delivering them to the community is what actually moves
> PostgreSQL forward.

*shrug*.  Robert asked me to write it up for the list based on the 
discussions around synch rep.  Now you're going to bash me for doing so?

Many of the goals I described will mean removing knobs and changing 
defaults, or even foregoing fine-grained control entirely.  If we don't 
have agreement that simplifying replication is a high-priority goal, 
then it won't happen; anyone submitting a patch will be 
this-or-that-use-cased to death and will give up.

For that matter, I'm not sure that everyone agrees that simplification 
is a worthwhile goal.  For example, somewhere between 9.0beta4 and final 
release, someone changed the defaults for max_wal_senders and 
hot_standby to "0" and "off".  I don't remember there even being 
discussion about it.

The discussion around synch rep certainly showed that the "natural" 
tendency of this list is to add complexity with each incarnation of a 
feature.  It's the easiest way to accomodate conflicting use cases, but 
it's not the best way.

-- 
                                   -- Josh Berkus
                                      PostgreSQL Experts Inc.
                                      http://www.pgexperts.com