Re: Future In-Core Replication

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Greg Smith <greg(at)2ndquadrant(dot)com>
Subject: Re: Future In-Core Replication
Date: 2012-05-04 16:59:41
Message-ID: 201205041859.41675.andres@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2012-05-04 17:26:08 Re: Future In-Core Replication
Previous Message Tom Lane 2012-05-04 16:58:51 Re: Beta time?