Re: Future In-Core Replication - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Future In-Core Replication
Date
Msg-id 201205041859.41675.andres@2ndquadrant.com
Whole thread Raw
In response to Re: Future In-Core Replication  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Future In-Core Replication
List pgsql-hackers
Hi Robert, Hi all,

On Friday, May 04, 2012 06:29:33 PM Robert Haas wrote:
> On Fri, May 4, 2012 at 11:06 AM, Greg Smith <greg@2ndquadrant.com> wrote:
> > The straw man argument here would require 100% transparency on everything
> > you do in regards to PostgreSQL and related software.  Before doing any
> > development on any code, first post here to ask for design review.  And
> > if someone asks you to work on a program that isn't open source from day
> > one, refuse unless you can operate that transparently.
> 
> Well, look.  At the end of the day, I don't really care whether you
> post your designs before writing code or not - unless it turns out
> that we get to the end of the development cycle, a gigantic patch
> shows up at the last minute, it gets rejected because people aren't
> satisfied with the design, and then massive bitching ensues because
> the author(s) put a lot of work into that patch.  Then I care, because
> now the fact that no design consensus was sought at the outset has
> been transformed into a defect in the community process, which does in
> fact have defects, but that isn't one of them.  We all know that
> design review is going to have to happen at some point, and if there's
> not an adequate opportunity to do that before the code is written then
> it will happen after the code is written.  If that means the code has
> to be thrown out, then that's the risk you take by writing the code
> first.  As long as everybody understands that, do it in whatever order
> you like.
In my understanding - as the person doing quite a bit of the coding atm - the 
point is to provide a very minimal *early* prototype to have a sensible basis 
for design decisions/discussions. On one side thats useful to get a feeling 
for the problems involved. On the other side doing design discussions without 
an underlaying basic patch & design on -hackers tends to often go into 
directions of feature creep and bikeshedding. It also helps against "this is 
impossible" claims.
Parts of this thread and related ones are a somewhat good example of this.

The plan is to show the early prototype around pgcon and send design documents 
and split-up patches (of that prototype) a holiday and some cleanup later to -
hackers. I/We aim to have individual, independently usable, parts of the patch 
submitted to the first 9.3 commitfest.

I definitely do not wish to screw anyone over doing this or such. And I am 
sure thats the same with others working on this. Even if sometimes emotions 
get in the way/into play.

Greetings,

Andres
-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Beta time?
Next
From: Robert Haas
Date:
Subject: Re: Future In-Core Replication