Re: [CORE] RC1 blocker issues

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Marc G(dot) Fournier" <scrappy(at)hub(dot)org>
Cc: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [CORE] RC1 blocker issues
Date: 2006-11-25 20:58:41
Message-ID: 9776.1164488321@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Marc G. Fournier" <scrappy(at)hub(dot)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 in
key_column_usage.position_in_unique_constraint column recently
added to information_schema (per a SQL2003 addition). The original
coding failed if a referenced column participated in more than one
pg_constraint entry. Also, it did not work if an FK relied
directly on a unique index without any constraint syntactic sugar
--- this case is outside the SQL spec, but PG has always supported
it, so it's reasonable for 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 serial
column, rather than the name of the associated sequence. Fallout
from recent changes in dependency setup for serials. Per bug #2732
from 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 and
sister views to put the recently-added vacuum/analyze timestamp
columns at the end, rather than at a random spot in the middle as
in 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Marc G. Fournier 2006-11-25 21:08:08 Re: [CORE] RC1 blocker issues
Previous Message Joshua D. Drake 2006-11-25 20:35:56 Re: [CORE] RC1 blocker issues