Re: damage control mode

Bruce Momjian wrote:
> I think the big issue with 8.4 was, do we close the commit-fest when we
> have open issues, and we aren't clear on how to fix them? A lot of
> unresolve issues get kept for that pre-beta period because all of a
> sudden we have to resolve all those complex problems. I don't see that
> changing for 8.5.
>
That's not quite how I remember it; let's compare directly. Right now
we have this: http://wiki.postgresql.org/wiki/PostgreSQL_8.5_Open_Items

And at this point in the year 8.4 looked like this:
http://wiki.postgresql.org/index.php?title=PostgreSQL_8.4_Open_Items&oldid=4121

You wrote a good summary of the open issues for 8.4 at the end of
January that I think is informative reading for how things are compared
with then:
http://archives.postgresql.org/message-id/200901270402.n0R42Xj01525@momjian.us

That point had three major features in it that all got pushed to 8.5,
and the whole in-place upgrade situation was also completely active as
well--Bruce finishing up a first good pg_migrator beta on 2009-02-18.
That one I'd consider a fourth major feature open at that point left off
that list.

Now, considering that list of four, one is committed this time around
(Hot standby), another quite clearly tabled already (SEPostgreSQL), the
third is still active but in much better shape (Streaming Replication),
and the fourth (in-place upgrade) just closed its main list of open
issues specific to this release.

How about bugs? The big data dump of open issues and known bugs that
Tom put together didn't show up until March 26:
http://wiki.postgresql.org/index.php?title=PostgreSQL_8.4_Open_Items&direction=prev&oldid=5588
http://archives.postgresql.org/message-id/24552.1238093548@sss.pgh.pa.us

Even with that whole mess, the 8.4 beta started on 2009-04-15, and 8.4.0
made it out on July 1.

Concerns about trimming the CF list are certainly valid, but I think any
comparison with 8.4 should recognize that there were four giant
patches/issues floating around at this point for that release, while
this time there's only a much closer to release SR. While the rest of
the patches Robert is concerned about have their complications and
aren't trivial, there's not a one of them that's anybody is going to
fight over the way HS, SEPostgreSQL, and in-place upgrades were. Not to
trivialize them or their authors work, but frankly changes to things
like Listen/Notify and the GIN/GIST changes that seem to be gathering
heat here seem pretty minor compared to the four giant things that were
open at this point in the 8.4 cycle--the controversial ones seem like
they have a pretty low destabilizing potential to me from what I've seen.

Personally, I'd like the topic of a thread on "damage control" to be all
about testing the one big patch that's already in there (HS), its
related bits like the VACUUM FULL changes, and potentially SR too.
Those are things that are touching internals that can introduce all
sorts of new bugs, in the same way that the FSM changes were pretty
scary for 8.4. Those are the things I worry about every day right now,
not whether, say, a very walled-off indexing change for data that only a
fraction of the user base uses might destabilize things. Getting
excited about pre-emptively kicking out patches that may not even be
commit candidates anyway is distracting thought from the stuff that
really matters right now IMHO. I'm more concerned about how to reach a
bug list as mature as the one Tom presented at the end of March last
year earlier in this one, for the features that are already in there.

(Oh, and to head off "well what are you doing about it?", I just updated
pgbench-tools this week to add some missing 8.4 features, eventually
working toward supporting some of the new 8.5 stuff before beta too.
I'm hoping to get a couple of months of machine testing time in between
now and release time.)

--
Greg Smith 2ndQuadrant Baltimore, MD
PostgreSQL Training, Services and Support
greg(at)2ndQuadrant(dot)com www.2ndQuadrant.com