Re: Streaming replication and postmaster signaling

On Thu, Jan 7, 2010 at 12:24 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Magnus Hagander <magnus(at)hagander(dot)net> writes:
>> We made the mistake last time to delay the release significantly for a
>> single feature. It turned out said feature didn't make it *anyway*.
>> Let's not repeat that mistake.
>
> Yeah, we've certainly learned that lesson often enough, or should I say
> failed to learn that lesson?

I think the latter phrasing is more accurate.

> However, HS is already in the tree, and HS without SR is a whole lot
> less compelling than HS with SR.  So it's going to be pretty
> unsatisfying if we can't get SR in there.
>
>
> I read Robert's original question not so much as a proposal to slip the
> schedule to accommodate SR as a question about whether SR could still
> meet the current schedule.  I think we ought to get that answered before
> we start debating schedule changes.

Unfortunately, we've also discovered from hard experience that the
timing of commits is difficult to predict unless the answer is
something like "today" or "tomorrow". I'm not terribly interested in
an estimate of when this will be committed if it's much more distant
than that because experience indicates that such estimates are
typically inaccurate, usually on the optimistic side. I seem to
recall Heikki estimating two weeks for SR about this time last year,
and of course it took a lot longer than that, even if you subtract out
the breaks in the action. That's not because Heikki is a bad
estimator; it's just that estimating how long a particular piece of
code will take to finish is extremely difficult and almost no one can
do it with any degree of accuracy. It is the things the programmer
can't foresee that push out the end date, and of course you can't know
how many of those there will be.

I like Andres' suggestion upthread of setting a deadline and
determining to bounce the patch if it's not committed by that date.
If it turns out we have to bounce it, that stinks, but I don't think
it makes sense to go to beta with a huge, barely-tested pile of code
in the tree. Not that the testing Heikki and Fujii Masao have been
doing until now hasn't been good, but it's not nearly as rigorous as
what we will get when all of our users start banging on it.

The problem with even TALKING about changing the schedule is that we
will have no idea what to change it TO. If we add two months to the
schedule today, that will probably increase the chances of SR getting
committed within that time frame (unless, of course, Heikki's employer
uses that as an excuse to take him off the project for two months...)
but we don't know how much because we can't predict how long it's
going to take to be ready. If someone could show us a curve with
probability on one axis and commit date on the other axis we could
probably make a good decision about where to slice it off, but that
isn't possible.

...Robert