Re: [CORE] RC1 blocker issues - Mailing list pgsql-hackers
From | Tom Lane |
---|---|
Subject | Re: [CORE] RC1 blocker issues |
Date | |
Msg-id | 9776.1164488321@sss.pgh.pa.us Whole thread Raw |
In response to | Re: [CORE] RC1 blocker issues ("Marc G. Fournier" <scrappy@hub.org>) |
Responses |
Re: [CORE] RC1 blocker issues
Re: [CORE] RC1 blocker issues Re: [CORE] RC1 blocker issues |
List | pgsql-hackers |
"Marc G. Fournier" <scrappy@hub.org> writes: > As rare as he and I agree ... I agree ... LISA is nice and all, but > end product *is* more important then timing, unless you are Microsoft, > of course :) I'm not concerned about announcing at LISA (though I know Josh is) ... but at the same time I want to get the thing out the door. I'm not sure that anything will be gained by further delay. This has been sort of a weird beta period, because it's the first one we've had where cleaning up portability problems has been a complete non-issue. The buildfarm has changed the rules of the game that way. Previously we've always had to allocate a fair amount of time for getting and dealing with port reports, but I don't think we need to do that anymore. So really the release decision is down to "at what point do we think it's stable enough to call it a release?". I think we're at that point already: I just looked through the CVS logs, and by my count there were 40 non-cosmetic patches applied to the main source tree (not doc/ or contrib/) during the past month. Of these all but three either were or could have been applied to 8.1 as well, ie, they fixed problems that exist in 8.1 or before. The three actual new-in-8.2 bugs found in the last thirty days are: 2006-11-10 13:10 tgl * backend/catalog/information_schema.sql: Fix errors inkey_column_usage.position_in_unique_constraint column recentlyaddedto information_schema (per a SQL2003 addition). The originalcoding failed if a referenced column participatedin more than onepg_constraint entry. Also, it did not work if an FK relieddirectly on a unique index withoutany constraint syntactic sugar--- this case is outside the SQL spec, but PG has always supportedit, so it's reasonablefor our information_schema to handle it too.Per bug#2750 from Stephen Haberman. 2006-11-10 17:59 tgl * backend/utils/adt/ruleutils.c: Fix pg_get_serial_sequence(),which could incorrectly return the name of an index on a serialcolumn,rather than the name of the associated sequence. Falloutfrom recent changes in dependency setup for serials. Per bug #2732from Basil Evseenko. 2006-11-24 16:18 tgl * backend/catalog/system_views.sql, backend/utils/adt/genfile.c,include/catalog/catversion.h, include/catalog/pg_proc.h,test/regress/expected/rules.out:Change pg_stat_all_tables andsister views to put the recently-addedvacuum/analyze timestampcolumns at the end, rather than at a random spot in the middle asin the original patch. That last one barely even qualifies as a bug; it's a cosmetic improvement. So it's now a solid two weeks since we found a real new bug. So if you ask me, we are past the point of diminishing returns for the current level of testing. Putting out an RC might draw the attention of a few more people, but really the only way we are going to find more bugs is to put out a release. Or perhaps knock heads together a little harder on pgsql-hackers to make people think less about 8.3 development and more about 8.2 testing, but how successful is that likely to be? regards, tom lane
pgsql-hackers by date: