Thread: When is 7.0 going Beta?
Hello, I was just wondering if there were any dates the major developers had in mind as to when current will be released as a beta release? For my trivial part, I still have to send in a patch to allow pg_dump to dump COMMENT ON commands for any descriptions the user might have created and was wondering if any time frame had been established. Just curious, Mike
Non set in stone at this time...mid-Feb, I believe, was the last that was
thrown around...
On Sat, 4 Dec 1999, Mike Mascari wrote:
> Hello,
>
> I was just wondering if there were any dates the major
> developers had in mind as to when current will be released
> as a beta release? For my trivial part, I still have to send
> in a patch to allow pg_dump to dump COMMENT ON commands for
> any descriptions the user might have created and was
> wondering if any time frame had been established.
>
> Just curious,
>
> Mike
>
>
>
>
> ************
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> I was just wondering if there were any dates the major
> developers had in mind as to when current will be released
> as a beta release? For my trivial part, I still have to send
> in a patch to allow pg_dump to dump COMMENT ON commands for
> any descriptions the user might have created and was
> wondering if any time frame had been established.
My recollection was that February has been discussed. But since it is
a major rev bump we would rather get the features which (perhaps) have
been waiting for a major rev, and these big changes may influence the
beta date...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
Thomas Lockhart wrote: > > > I was just wondering if there were any dates the major > > developers had in mind as to when current will be released > > as a beta release? For my trivial part, I still have to send > > in a patch to allow pg_dump to dump COMMENT ON commands for > > any descriptions the user might have created and was > > wondering if any time frame had been established. > > My recollection was that February has been discussed. But since it is > a major rev bump we would rather get the features which (perhaps) have > been waiting for a major rev, and these big changes may influence the > beta date... Seems that I'll be able to return to WAL development in Feb only. So, good beta date for me is Apr/May... Sorry, but... life is life. Vadim
Vadim Mikheev <vadim@krs.ru> writes:
> Seems that I'll be able to return to WAL development in Feb
> only. So, good beta date for me is Apr/May...
> Sorry, but... life is life.
I'm not anywhere near "ready" either, at least if "ready" means all the
stuff I'd hoped to get done for 7.0.
If we want to do a schedule-driven release around Feb, fine, but let's
call it 6.6. 7.0 ought to be driven by features not calendar.
regards, tom lane
On Sun, 5 Dec 1999, Tom Lane wrote:
> Vadim Mikheev <vadim@krs.ru> writes:
> > Seems that I'll be able to return to WAL development in Feb
> > only. So, good beta date for me is Apr/May...
> > Sorry, but... life is life.
>
> I'm not anywhere near "ready" either, at least if "ready" means all the
> stuff I'd hoped to get done for 7.0.
>
> If we want to do a schedule-driven release around Feb, fine, but let's
> call it 6.6. 7.0 ought to be driven by features not calendar.
I believe that we've already agreed that there are features going into the
source tree currently that are prompting a 7.0 release...I have no qualms
at all about holding off the next release until Apr/May, as long as we
continue with what we've started, and that is back-patching appropriate
changes to the -STABLE source tree and putting out a minor release
periodically...
I'd like to stick with the next "full release" being 7.0 ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> Vadim Mikheev <vadim@krs.ru> writes: > > Seems that I'll be able to return to WAL development in Feb > > only. So, good beta date for me is Apr/May... > > Sorry, but... life is life. > > I'm not anywhere near "ready" either, at least if "ready" means all the > stuff I'd hoped to get done for 7.0. > > If we want to do a schedule-driven release around Feb, fine, but let's > call it 6.6. 7.0 ought to be driven by features not calendar. I am concerned about a May release. That puts us at almost a year from the last major release in mid-June. That is too long. Seems like we should have some release around February. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
> I am concerned about a May release. That puts us at almost a year from
> the last major release in mid-June. That is too long. Seems like we
> should have some release around February.
Let's list the 7.0 items:
Foreign Keys - Jan WAL - Vadim Function args - Tom System indexes -
Bruce Date/Time types - Thomas Optimizer - Tom Outer Joins - Thomas? Long Tuples
- ?
None of these are done, except for the system indexes, and that is a
small item. It seems everyone wants a grand 7.0, but that is months
away.
I propose we go into beta on 6.6 Jan 1, with final release Feb 1. We
certainly have enough for a 6.6 release.
I recommend this so the 6.5.* enhancements are accessible to users now,
rather than waiting another severel months while we add the above fancy
features.
Also, I have never been a big fan of huge, fancy releases because they
take too long to become stable. Better for us to release what we have
now and work out those kinks.
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
What do we have now for a v6.6? I'm not against, just wondering if we have enough to warrant a v6.6, that's all... On Mon, 6 Dec 1999, Bruce Momjian wrote: > > I am concerned about a May release. That puts us at almost a year from > > the last major release in mid-June. That is too long. Seems like we > > should have some release around February. > > Let's list the 7.0 items: > > Foreign Keys - Jan > WAL - Vadim > Function args - Tom > System indexes - Bruce > Date/Time types - Thomas > Optimizer - Tom > > Outer Joins - Thomas? > Long Tuples - ? > > None of these are done, except for the system indexes, and that is a > small item. It seems everyone wants a grand 7.0, but that is months > away. > > I propose we go into beta on 6.6 Jan 1, with final release Feb 1. We > certainly have enough for a 6.6 release. > > I recommend this so the 6.5.* enhancements are accessible to users now, > rather than waiting another severel months while we add the above fancy > features. > > Also, I have never been a big fan of huge, fancy releases because they > take too long to become stable. Better for us to release what we have > now and work out those kinks. > > -- > Bruce Momjian | http://www.op.net/~candle > maillist@candle.pha.pa.us | (610) 853-3000 > + If your life is a hard drive, | 830 Blythe Avenue > + Christ can be your backup. | Drexel Hill, Pennsylvania 19026 > > ************ > Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
Bruce Momjian wrote:
>
> > I am concerned about a May release. That puts us at almost a year from
> > the last major release in mid-June. That is too long. Seems like we
> > should have some release around February.
>
> Let's list the 7.0 items:
> [...]
> None of these are done, except for the system indexes, and that is a
> small item. It seems everyone wants a grand 7.0, but that is months
> away.
>
> I propose we go into beta on 6.6 Jan 1, with final release Feb 1. We
> certainly have enough for a 6.6 release.
#define READ_BETWEEN_LINES true
THAT'S MY CHANCE :-)
Let's not call it 6.6, instead it should read 6.6.6 - the
BEASTS release. That number could probably make serious
database users/admins look somewhat more careful at the
release notes.
> Also, I have never been a big fan of huge, fancy releases because they
> take too long to become stable. Better for us to release what we have
> now and work out those kinks.
#define READ_BETWEEN_LINES false
With all the PARTIALLY developed and COMMITTED fancy 7.0
features inside, do you really think that release would be
easy to get stable? I fear the partial features we already
have inside lead to a substantial increase in mailing list
traffic.
As far as I've read the responses, the users community called
6.5 one of the best releases ever made. Many nice, new
features and an outstanding quality WRT reliability and
performance. Never underestimate the users community hearsay
in open source - don't play with our reputation!
If we really go for a 6.6 release, we need to branch off from
the 6.5 tree and backpatch things we want to have in 6.6 into
there. Releasing some snapshot of the current 7.0 tree as 6.6
IMHO is a risk we cannot estimate.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
wieck@debis.com (Jan Wieck) writes:
> If we really go for a 6.6 release, we need to branch off from
> the 6.5 tree and backpatch things we want to have in 6.6 into
> there. Releasing some snapshot of the current 7.0 tree as 6.6
> IMHO is a risk we cannot estimate.
I agree with Jan that we can't just fire something out the door based
on current sources. There are enough poorly-tested or half-done
changes in there that we'd need a long beta cycle to have much
confidence in it. I think this would drain an unreasonable amount of
developer time that would be better spent on finishing the half-done
stuff ... and *then* starting a long beta cycle ;-).
We are at a midflight point now. We don't have enough stuff done to
put out a 7.0, but neither are we close enough to the last release
to put out something that would fairly be called 6.6. I think users
would expect a "6.6" to offer small improvements featurewise and
continue in the trend of improving stability/performance. I'm not
sure I could promise that a 6.6 would be more stable than 6.5. At
least not without that long beta cycle.
We can continue to make 6.5.* releases if any critical problems come up,
but that again is a drain on developer time, so I'm not enthused about
making 6.5.* releases unless necessary.
In short, I'd rather continue on the present course and not be overly
concerned about how long it takes to get it right. Schedule-driven
decisions are usually wrong decisions, in my experience.
regards, tom lane
I personally agree with Jan on this...I think most users have found that
our releases have been "worth the wait", and altho we're askign them to
wait a little bit longer then normal, we *are* addressing problems with he
current release by putting out 6.5.x's as required, *and* we are highly
visible.
unlike some projects out there (gcc's "past" coming to mind), we have a
highly active mailing list where developers are constantly putting out,
and discussing, news ideas...the end user sees this, and with what is on
the todo list, 7.0 will be *more* worth the wait then our past
releases...7.0 is looking to be our *biggest* release yet, a little more
time will be required on this one...
On Tue, 7 Dec 1999, Jan Wieck wrote:
> Bruce Momjian wrote:
> >
> > > I am concerned about a May release. That puts us at almost a year from
> > > the last major release in mid-June. That is too long. Seems like we
> > > should have some release around February.
> >
> > Let's list the 7.0 items:
> > [...]
> > None of these are done, except for the system indexes, and that is a
> > small item. It seems everyone wants a grand 7.0, but that is months
> > away.
> >
> > I propose we go into beta on 6.6 Jan 1, with final release Feb 1. We
> > certainly have enough for a 6.6 release.
>
> #define READ_BETWEEN_LINES true
>
> THAT'S MY CHANCE :-)
>
> Let's not call it 6.6, instead it should read 6.6.6 - the
> BEASTS release. That number could probably make serious
> database users/admins look somewhat more careful at the
> release notes.
>
> > Also, I have never been a big fan of huge, fancy releases because they
> > take too long to become stable. Better for us to release what we have
> > now and work out those kinks.
>
> #define READ_BETWEEN_LINES false
>
> With all the PARTIALLY developed and COMMITTED fancy 7.0
> features inside, do you really think that release would be
> easy to get stable? I fear the partial features we already
> have inside lead to a substantial increase in mailing list
> traffic.
>
> As far as I've read the responses, the users community called
> 6.5 one of the best releases ever made. Many nice, new
> features and an outstanding quality WRT reliability and
> performance. Never underestimate the users community hearsay
> in open source - don't play with our reputation!
>
> If we really go for a 6.6 release, we need to branch off from
> the 6.5 tree and backpatch things we want to have in 6.6 into
> there. Releasing some snapshot of the current 7.0 tree as 6.6
> IMHO is a risk we cannot estimate.
>
>
> Jan
>
> --
>
> #======================================================================#
> # It's easier to get forgiveness for being wrong than for being right. #
> # Let's break this rule - forgive me. #
> #========================================= wieck@debis.com (Jan Wieck) #
>
>
>
> ************
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
>
> I personally agree with Jan on this...I think most users have found that
> our releases have been "worth the wait", and altho we're askign them to
> wait a little bit longer then normal, we *are* addressing problems with he
> current release by putting out 6.5.x's as required, *and* we are highly
> visible.
>
> unlike some projects out there (gcc's "past" coming to mind), we have a
> highly active mailing list where developers are constantly putting out,
> and discussing, news ideas...the end user sees this, and with what is on
> the todo list, 7.0 will be *more* worth the wait then our past
> releases...7.0 is looking to be our *biggest* release yet, a little more
> time will be required on this one...
OK, seeing as everyone disagrees with me...
Other than WAL, what else is half-completed and installed?
Foreign Keys - Jan WAL - Vadim Function args - Tom Date/Time types - Thomas
Optimizer - Tom
Outer Joins - Thomas? Long Tuples - ?
I guess I am wondering, other than WAL, what makes our current state
any worse than the time before previous beta cycles
I am very hesitant about our "one big release" thing coming? If we wait
for everything to get done, we would never have a release.
The more items in a release, the longer the beta cycle. If you wait too
long, you are fixing code you wrote 6 months ago, and that makes it very
hard. Smaller releases where the code is relatively fresh and the
additional features minimal are cleaner, faster betas.
The concern about a release sapping our energy when we should be adding
code is valid, but this delays how soon users can use the items we
_have_ finished.
Our 6.5.* subreleases are actually allowing us to take longer between
releases because we don't have to fix that _major_ bug a new release.
We fix it in the subrelease.
Obviously, no one agrees with me, so it looks like May.
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
Bruce Momjian wrote:
> OK, seeing as everyone disagrees with me...
BADDAY.MPG?
Wasn't that I completely disagreed. Just that in the actual
case, I don't think we can make another release out of the
current tree. And about that I'm not alone.
> Other than WAL, what else is half-completed and installed?
>
> Foreign Keys - Jan
> WAL - Vadim
> Function args - Tom
> Date/Time types - Thomas
> Optimizer - Tom
>
> Outer Joins - Thomas?
> Long Tuples - ?
>
> I guess I am wondering, other than WAL, what makes our current state
> any worse than the time before previous beta cycles
At least FK. Just found myself a bug that makes things ugly.
Forces CKECK lookup in PK table even if FK values didn't
change on trigger invocation - otherwise someone could cause
RI violation not recognized by deleting DEFAULT key values of
FK from PK table.
That's IMHO something so easily to trigger, that I expect
more bugs in the stuff.
Since FOREIGN KEY is a feature so many ppl asked for, I
expect many of them penetrating the lists if things go bad -
what's really possible for now. Thus, I wouldn't feel
comfortable if it goes out in this state.
> I am very hesitant about our "one big release" thing coming? If we wait
> for everything to get done, we would never have a release.
>
> The more items in a release, the longer the beta cycle. If you wait too
> long, you are fixing code you wrote 6 months ago, and that makes it very
> hard. Smaller releases where the code is relatively fresh and the
> additional features minimal are cleaner, faster betas.
Hmmm,
yes and no. Yes, the more items the longer beta. But no, the
longer beta the better the release.
The last release had the longest of all beta delays. And it
was the best of all releases. Maybe because while feature A
prevents release, another bug in feature H shows up while B-G
are silent, but after fixing H's bug F shout's "stop". Not
surprising - (real) programmers experience.
The worst thing we can do is to release FEATURES, that are
current development state and must be deprecated because they
interfere with ongoing development. I just saw that someone
added some kind of subselect inside or the targetlist - and I
absolutely don't know if that will stand the test of time
(i.e. issues WRT the rewriter MIGHT be more important). So
that syntax might need to be removed/changed in 7.0 or a
subsequent release again.
> The concern about a release sapping our energy when we should be adding
> code is valid, but this delays how soon users can use the items we
> _have_ finished.
I don't see any (of the important) issues finished.
> Obviously, no one agrees with me, so it looks like May.
At least not me.
May? Vadim said he could probably come back to finish WAL by
April/May. And I'm so bored about the tuple split stuff up
to now, that I don't know if I should start on it for 7.0
right now. So May (optimistic) might be start of BETA - not
release.
And AFAIK, if we start beta that long after our last release,
the next wouldn't be out before July.
That would give me enough time for the other thing (Bruce
knows what I'm talking about).
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
>
>
> What do we have now for a v6.6? I'm not against, just wondering if we
> have enough to warrant a v6.6, that's all...
>
Just from completed TODO list items I have many. This doesn't count the
non-list items like the psql rewrite and other big stuff that never made
it to this list. If this gets people interested, I can generate a full
log dump to show the items.
* -Recover or force failure when disk space is exhausted(Hiroshi)
* -INSERT INTO ... SELECT with AS columns matching result columns problem
* -Select a[1] FROM test fails, it needs test.a[1](Tom)
* -Array index references without table name cause problems [array](Tom)
* -INSERT ... SELECT ... GROUP BY groups by target columns not source columns(Tom)
* -CREATE TABLE test (a char(5) DEFAULT text '', b int4) fails on INSERT(Tom)
* -UNION with LIMIT fails
* -CREATE TABLE x AS SELECT 1 UNION SELECT 2 fails
* -CREATE TABLE test(col char(2) DEFAULT user) fails in length restriction
* -mismatched types in CREATE TABLE ... DEFAULT causes problems [default]
* -select * from pg_class where oid in (0,-1)
* -SELECT COUNT('asdf') FROM pg_class WHERE oid=12 crashes
* -require SELECT DISTINCT target list to have all ORDER BY columns
* -When using aggregates + GROUP BY, no rows in should yield no rows out(Tom)
* -Allow HAVING to use comparisons that have no aggregates(Tom)
* -Eliminate limits on query length
* -Fix memory leak for aggregates(Tom)
* -Allow compression of large fields or a compressed field type
* -Allow pg_descriptions when creating tables
* -Allow pg_descriptions when creating types, columns, and functions
* -Add index on NUMERIC/DECIMAL type(Jan)
* -Move LIKE index optimization handling to the optimizer(Tom)
* -Allow psql \copy to allow delimiters
* -Add a function to return the last inserted oid, for use in psql scripts
* -Allow psql to print nulls as distinct from "" [null]
* -Certain indexes will not shrink, i.e. oid indexes with many inserts(Vadim)
* -Allow WHERE restriction on ctid(Hiroshi)
* -Transaction log, so re-do log can be on a separate disk by
* -Allow subqueries in target list
* -Overhaul mdmgr/smgr to fix double unlinking and double opens, cleanup
* -Allow transaction commits with rollback with no-fsync performance [fsync](Vadim)
* -Prevent fsync in SELECT-only queries(Vadim)
* -Convert function(constant) into a constant for index use(Tom)
* -Make index creation use psort code, because it is now faster(Vadim)
* -Allow creation of sort temp tables > 1 Gig
* -Allow optimizer to prefer plans that match ORDER BY(Tom)
* -Fix memory exhaustion when using many OR's [cnfify](Tom)
* -Process const = const parts of OR clause in separate pass(Tom)
* -Add needed includes and removed unneeded include files(Bruce)
* -Make configure --enable-debug add -g on compile line
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
Here's my "fear"...we go beta on jan 1st, for a 6.6 ... if last beta was
any indication, we're talking 2-3 months of beta, so March/April before we
do a release, which disrupts everything that those working on v7.0
features is working on...plus, while debugging, it distracts them from
that work.
If we wait to break into Beta around June 1st, we're still going tobe
talking 2-3mos of beta work, max, so Sept 1 or so for a release...
We're to the point of "competing with the big boys"...how often does
Oracle release?
How about this? Out of the list below, how many can be *safely*
back-patched to the -STABLE tree? The kind of thing where ppl are
*confident* enough that we could put out a v6.5.4 based on those patches?
I would rather see the *safe* ones backpatched and a v6.5.4 released, then
tie up ppl working v7.0 features with debugging an interim release, but
that's just me :(
On Mon, 6 Dec 1999, Bruce Momjian wrote:
> >
> >
> > What do we have now for a v6.6? I'm not against, just wondering if we
> > have enough to warrant a v6.6, that's all...
> >
>
> Just from completed TODO list items I have many. This doesn't count the
> non-list items like the psql rewrite and other big stuff that never made
> it to this list. If this gets people interested, I can generate a full
> log dump to show the items.
>
>
> * -Recover or force failure when disk space is exhausted(Hiroshi)
> * -INSERT INTO ... SELECT with AS columns matching result columns problem
> * -Select a[1] FROM test fails, it needs test.a[1](Tom)
> * -Array index references without table name cause problems [array](Tom)
> * -INSERT ... SELECT ... GROUP BY groups by target columns not source columns(Tom)
> * -CREATE TABLE test (a char(5) DEFAULT text '', b int4) fails on INSERT(Tom)
> * -UNION with LIMIT fails
> * -CREATE TABLE x AS SELECT 1 UNION SELECT 2 fails
> * -CREATE TABLE test(col char(2) DEFAULT user) fails in length restriction
> * -mismatched types in CREATE TABLE ... DEFAULT causes problems [default]
> * -select * from pg_class where oid in (0,-1)
> * -SELECT COUNT('asdf') FROM pg_class WHERE oid=12 crashes
> * -require SELECT DISTINCT target list to have all ORDER BY columns
> * -When using aggregates + GROUP BY, no rows in should yield no rows out(Tom)
> * -Allow HAVING to use comparisons that have no aggregates(Tom)
> * -Eliminate limits on query length
> * -Fix memory leak for aggregates(Tom)
> * -Allow compression of large fields or a compressed field type
> * -Allow pg_descriptions when creating tables
> * -Allow pg_descriptions when creating types, columns, and functions
> * -Add index on NUMERIC/DECIMAL type(Jan)
> * -Move LIKE index optimization handling to the optimizer(Tom)
> * -Allow psql \copy to allow delimiters
> * -Add a function to return the last inserted oid, for use in psql scripts
> * -Allow psql to print nulls as distinct from "" [null]
> * -Certain indexes will not shrink, i.e. oid indexes with many inserts(Vadim)
> * -Allow WHERE restriction on ctid(Hiroshi)
> * -Transaction log, so re-do log can be on a separate disk by
> * -Allow subqueries in target list
> * -Overhaul mdmgr/smgr to fix double unlinking and double opens, cleanup
> * -Allow transaction commits with rollback with no-fsync performance [fsync](Vadim)
> * -Prevent fsync in SELECT-only queries(Vadim)
> * -Convert function(constant) into a constant for index use(Tom)
> * -Make index creation use psort code, because it is now faster(Vadim)
> * -Allow creation of sort temp tables > 1 Gig
> * -Allow optimizer to prefer plans that match ORDER BY(Tom)
> * -Fix memory exhaustion when using many OR's [cnfify](Tom)
> * -Process const = const parts of OR clause in separate pass(Tom)
> * -Add needed includes and removed unneeded include files(Bruce)
> * -Make configure --enable-debug add -g on compile line
>
> --
> Bruce Momjian | http://www.op.net/~candle
> maillist@candle.pha.pa.us | (610) 853-3000
> + If your life is a hard drive, | 830 Blythe Avenue
> + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Other than WAL, what else is half-completed and installed?
WAL is probably the thing that forces our hand here. Vadim would know
better than anyone else whether the current state of the code is
releasable, but I bet he'll say "no".
However, I've got a couple of nontrivial concerns:
1. Table locking and shared-cache-invalidation (SI) handling. We've
made some fundamental changes in this area since 6.5, but I don't think
we're done yet. I know Hiroshi is very worried about this area, and
I'm not happy with it either. And this is the kind of thing we cannot
expect to validate with a short beta test cycle. I won't be happy until
I am logically convinced that the code is right, *and* we see solid
behavior in heavy beta testing.
2. Optimizer's handling of order-by cases, specifically whether to use
an index scan or an explicit sort. The current code is (finally!) able
to use an index scan in all the cases where one is applicable ... but it
is *too* eager to do so, because the cost model is underestimating the
cost of an index scan. If we don't fix that I think we will see
substantial performance degradation in some real-world cases, compared
to 6.5 which avoided some losing index scans simply because it was too
stupid to consider them. In particular, we really need some
consideration of the effects of LIMIT in there, because that has a huge
impact on the desirability of index scan vs. sort.
3. Alpha (and other platforms) porting problems. We're still hanging
fire on the issue of what to do about these. If we don't do the fmgr
rewrite the way I want, I think we have to put in the Alpha patches that
Uncle George did... and I'd rather we didn't hack up the code that
way...
> The more items in a release, the longer the beta cycle. If you wait too
> long, you are fixing code you wrote 6 months ago, and that makes it very
> hard. Smaller releases where the code is relatively fresh and the
> additional features minimal are cleaner, faster betas.
This is true, but it's also very hard to accomplish really large changes
that way. Some of the things we're trying to get done in this release
are pretty pervasive changes. I think every so often you need a slow-
birthing release where you take time to tackle big things. I don't want
to make a habit of slow releases either, but I see plenty of reasons to
take our time with this one.
regards, tom lane
Tom Lane wrote: > > Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Other than WAL, what else is half-completed and installed? > > WAL is probably the thing that forces our hand here. Vadim would know > better than anyone else whether the current state of the code is > releasable, but I bet he'll say "no". No. -:) But it's very easy to turn current functionality off - WAL is called on startup/shutdown only, so, just ~10 lines of code to do nothing here... Vadim
On Mon, 6 Dec 1999, Bruce Momjian wrote: > I propose we go into beta on 6.6 Jan 1, with final release Feb 1. We > certainly have enough for a 6.6 release. Just to add my two cents here, a Jan 1 feature-freeze is most definitely not going to work for my part, as there are still some subtle and not so subtle things to tie up. -- Peter Eisentraut Sernanders vaeg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Other than WAL, what else is half-completed and installed?
>
> WAL is probably the thing that forces our hand here. Vadim would know
> better than anyone else whether the current state of the code is
> releasable, but I bet he'll say "no".
OK, seems Vadim can turn this off easily, which is what I expected.
The big question is whether we want to stop working on the "features"
list to put out a release?
We have a list of stuff, but other than the first two, they are not
being developed in the current tree, or are not started:
Foreign Keys - Jan WAL - Vadim Function args - Tom Date/Time types - Thomas
Optimizer - Tom
Outer Joins - Thomas? Long Tuples - ?
Seems the general agreement is that people don't want to stop for 2-3
months to polish what we have done so far. They want to use those 2-3
months for development of the above items.
That is fine, as long as everyone realizes we are going +1 year between
major releases in this case, and that in the period from June to
current, we only have two of these items partially done.
I agree we really don't have a MVCC-type feature to justify a 6.6 at
this time. If Jan could get foreign keys partially working for the
common cases, that may be enough to tip the scales.
I have never been a big release fan. I like to get the code out to the
users. Every release seems to be bigger than the last.
Marc, as far as backpatching, you really can't do that without going
into beta on the release, and if you do that, you might as well use the
current tree. Each patch has already been evaluated for backpatching.
Sorry, no free lunch there.
Another secret is that deadlines generate features. As beta approaches,
things seem to happen much faster.
However, since no one else agrees, I will drop the topic now.
-- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610)
853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill,
Pennsylvania19026
> On Mon, 6 Dec 1999, Bruce Momjian wrote: > > > I propose we go into beta on 6.6 Jan 1, with final release Feb 1. We > > certainly have enough for a 6.6 release. > > Just to add my two cents here, a Jan 1 feature-freeze is most definitely > not going to work for my part, as there are still some subtle and not so > subtle things to tie up. That is interesting, because Peter's psql changes are some of the features I wanted to get out to users in 6.6. -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Tue, 7 Dec 1999, Bruce Momjian wrote: > > Just to add my two cents here, a Jan 1 feature-freeze is most definitely > > not going to work for my part, as there are still some subtle and not so > > subtle things to tie up. > > That is interesting, because Peter's psql changes are some of the > features I wanted to get out to users in 6.6. In case you're interested, this is what definitely still needs to be done: * \e to edit previous query * match up \do with COMMENT ON OPERATOR * actually fix up those comments in the catalogues * smoothen out tab completion * write a Windows makefile [ <--- up for grabs! ] * re-generate regression tests * make sure the output looks like it should before doing the above * (maybe more) These are all not very challenging but do take time, which I currently don't have. Also, I think there are some problems with using psql with old servers, in particular some internal queries generated by \dd or \do create weird notices. -- Peter Eisentraut Sernanders vaeg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
Bruce Momjian <pgman@candle.pha.pa.us> el día Mon, 6 Dec 1999 22:00:26 -0500 (EST), escribió: >I am very hesitant about our "one big release" thing coming? If we wait >for everything to get done, we would never have a release. and if you declare a feature-freeze at some point ? Sergio
On Tue, 7 Dec 1999, Bruce Momjian wrote:
> > On Mon, 6 Dec 1999, Bruce Momjian wrote:
> >
> > > I propose we go into beta on 6.6 Jan 1, with final release Feb 1. We
> > > certainly have enough for a 6.6 release.
> >
> > Just to add my two cents here, a Jan 1 feature-freeze is most definitely
> > not going to work for my part, as there are still some subtle and not so
> > subtle things to tie up.
>
> That is interesting, because Peter's psql changes are some of the
> features I wanted to get out to users in 6.6.
But, as Peter pop'd up, he's not ready for a Beta yet either :)
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
On Tue, 7 Dec 1999, Bruce Momjian wrote:
> > Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > > Other than WAL, what else is half-completed and installed?
> >
> > WAL is probably the thing that forces our hand here. Vadim would know
> > better than anyone else whether the current state of the code is
> > releasable, but I bet he'll say "no".
>
> OK, seems Vadim can turn this off easily, which is what I expected.
>
> The big question is whether we want to stop working on the "features"
> list to put out a release?
No
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> > OK, seems Vadim can turn this off easily, which is what I expected.
> > The big question is whether we want to stop working on the "features"
> > list to put out a release?
> No
Hmm. istm that several of the folks expecting to make major changes
for a 7.0 release are not able to work on it (much anyway) for the
next couple of months. Tom Lane is the only one to have feet in both
camps (big (?) changes already committed, more coming) but perhaps he
might reconsider his vote for "no 6.6". A 6.6 release cycle would get
that stuff out in the field and tested soon (Jan/Feb timeframe) rather
than waiting 'til May/June to start intensive testing.
I know that we made the commitment for v7.0 (and that waffling on that
issue for past releases drove me nuts ;), but I suspect that what we
already have in the code tree could come close to standing on its own
(especially in light of easily disabling the WAL framework, per
Vadim's note).
I could have "join syntax" ready for a 6.6 (no major changes to the
query tree required), then do the outer joins (with bigger query
tree/optimizer changes) and date/time reunification for 7.0...
- Thomas
Maybe we could steal Scott McNealy's (of Sun Microsystems) term for
Win2K for our 7.0 release:
"The big hairball"
:))
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
On Tue, 7 Dec 1999, Thomas Lockhart wrote: > > > OK, seems Vadim can turn this off easily, which is what I expected. > > > The big question is whether we want to stop working on the "features" > > > list to put out a release? > > No > > Hmm. istm that several of the folks expecting to make major changes > for a 7.0 release are not able to work on it (much anyway) for the > next couple of months. Tom Lane is the only one to have feet in both > camps (big (?) changes already committed, more coming) but perhaps he > might reconsider his vote for "no 6.6". A 6.6 release cycle would get > that stuff out in the field and tested soon (Jan/Feb timeframe) rather > than waiting 'til May/June to start intensive testing. Then why not just move 7.0 up to Mar/Apr (or even Feb/Mar) and plan on the other new stuff for 7.1 if it's not ready? Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null # include <std/disclaimers.h> Have you seenhttp://www.pop4.net? Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
> Then why not just move 7.0 up to Mar/Apr (or even Feb/Mar) and plan on
> the other new stuff for 7.1 if it's not ready?
Even though we make pretty major changes for "minor releases", istm
7.0 should be the release which is the sum of what we've been working
towards in the v6.x series. It would include WAL, outer joins,
integrated date/time, reworked locking, referential integrity,
reworked parse/query tree, yada yada yada...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
Thomas Lockhart <lockhart@alumni.caltech.edu> writes:
> I know that we made the commitment for v7.0 (and that waffling on that
> issue for past releases drove me nuts ;), but I suspect that what we
> already have in the code tree could come close to standing on its own
> (especially in light of easily disabling the WAL framework, per
> Vadim's note).
As Bruce's list reminds us, there are a lot of nice fixes in place
already. I'm not changing my vote (yet), but let's just think a little
further on this...
Considering Bruce's "major items":
WAL: if we can turn it off and leave it in the tree, then this could be
postponed past a 6.6 release.
Foreign keys: Jan has made some commits; features are there but probably
rather broken. As long as the FK stuff is unlikely to break any *existing*
functionality (Jan, do you think that's a safe assumption?) it'd be OK
to leave it in the tree, documented as "work in progress, use at your
own risk". Getting feedback from users might actually help with the
debugging here.
Date/Time types: no commits yet, but because of compatibility issues
we'd want to postpone this to 7.0 anyway.
Function arg changes: same comments. However, we'd have to plug in
Uncle George's Alpha fixes instead. Those are ugly, but I could live
with them as a short-term hack.
Optimizer: really needs some work, but perhaps not very much to get to a
releasable state. Much of what I'd hoped to do for 7.0 could be put off.
Outer joins: As yet no commits, and I'd be inclined to say "leave it
that way for 6.6".
Long tuples: not started, postpone to 7.0.
Query tree redesign: not started, postpone to 7.0.
Things Bruce didn't list:
psql: not ready for prime time, according to Peter (who should know ;-)).
Table locking/SI handling: also not ready for prime time.
Long queries: although this area is almost done, we cannot release
without fixing pg_dump, else it will choke on complex table definitions
and rules that are now possible. Michael Ansley is working on this ---
Michael, do you have an ETA? I think there were some loose ends in
some of the interface libraries, too.
So, if we refocused our energies into cleaning up these items, we
probably could make a reasonable 6.6 release. I'd have to say that
1 Jan is too soon for beta freeze --- dunno about you guys, but family
commitments and Christmas shopping are going to be soaking up most of my
spare cycles through New Year's Day. I can't promise to get much of
anything done until January. 1 Feb would be a reasonable date for me.
I think Hiroshi and I could have the locking stuff solved by then, and
I could find some time to do what must be done in the optimizer. If
Peter can have psql in a presentable state by 1 Feb, it could work.
There is an awful lot to be said for finishing undone work and getting
it out the door to people who need it. Bruce has a good point about
how difficult it is to remember what you were doing 6 months ago.
On the other hand, if we do this then serious 7.0 feature development
will probably not resume till about May, which is a long way off.
Maybe that's a good tradeoff for consolidating our current gains and
getting a beta-test cycle under our belts for what we have already done.
Comments? What other stuff do we have in progress that needs to be
taken into account?
At this point I'm sitting on the fence --- I can see the arguments for
going either way. But I think I might be leaning in favor of a 6.6,
unless someone points out an issue I missed.
regards, tom lane
On Tue, 7 Dec 1999, Thomas Lockhart wrote: > > Then why not just move 7.0 up to Mar/Apr (or even Feb/Mar) and plan on > > the other new stuff for 7.1 if it's not ready? > > Even though we make pretty major changes for "minor releases", istm > 7.0 should be the release which is the sum of what we've been working > towards in the v6.x series. It would include WAL, outer joins, > integrated date/time, reworked locking, referential integrity, > reworked parse/query tree, yada yada yada... But wouldn't much of that end up in a 6.6 release leaving considerably less for 7.0? Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null # include <std/disclaimers.h> Have you seenhttp://www.pop4.net? Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
On Tue, 7 Dec 1999, Tom Lane wrote: > psql: not ready for prime time, according to Peter (who should know ;-)). I could also go for a Feb 1st deadline. By then I could also have some minor tweakage of initdb and makefiles done, and rewrite the INSTALL doc so the install process is easier. (Always a good selling point.) I would have to agree that waiting for all our 7.0 wishes to become true might mean an indefinite wait at the worst. Release early, release often is what makes open source projects successful. -- Peter Eisentraut Sernanders vaeg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
Tom Lane wrote:
> Foreign keys: Jan has made some commits; features are there but probably
> rather broken. As long as the FK stuff is unlikely to break any *existing*
> functionality (Jan, do you think that's a safe assumption?) it'd be OK
> to leave it in the tree, documented as "work in progress, use at your
> own risk". Getting feedback from users might actually help with the
> debugging here.
Not as safe as you probably want it.
Initially some ppl offered help for FK stuff. The basic's
have been committed for several weeks now, and no contributor
surfaced. So I don't expect any other help now than what I
already got - bug reports. And that's why I concentrated on
the parser/utility area, to get full support into CREATE
TABLE, and the completeness of MATCH FULL. Voila - a few
hours later I got the first bug report.
Now the bad part, the major change I did was the internal
change of the trigger manager to run driven by a deferred
invocation queue. That's the part that could hurt, because
it isn't complete. All trigger events are collected in memory
up to now, and during a huge transaction with millions of
trigger invocations, it could potentially blow away the
backend. Not only RI triggers, ALL trigger events must run
through the queue, and it must remember anything from the
beginning to detect the "triggered data change" violation or
decide what the actual operation really is and which trigger
to invoke finally.
This queue must be able to use a temp file in the case it
grows too big. Since I cannot easily rollback these changes,
it's a show stopper. I knew that from the beginning and
wouldn't have committed that if we hadn't agreed on 7.0 for
the next release. This work is now delayed due to the missed
help, and it must be delayed more to build a multibackend
test driver. Hiroshi's report showed, that especially
referential integrity tests don't make much sense if run by a
single backend serialized.
> At this point I'm sitting on the fence --- I can see the arguments for
> going either way. But I think I might be leaning in favor of a 6.6,
> unless someone points out an issue I missed.
From my point of view, we could start BETA for a 6.6.6 when I
have the temp file buffered queue and the multibackend driver
plus a test suite ready. Even if I don't like it, personally.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#========================================= wieck@debis.com (Jan Wieck) #
wieck@debis.com (Jan Wieck) writes:
> This queue must be able to use a temp file in the case it
> grows too big. Since I cannot easily rollback these changes,
> it's a show stopper.
OK, so having the queue file is a must-do before we could release a 6.6.
(BTW, please consider using storage/file/buffile.c for the queue file;
that handles virtual-file access, segmenting of multi-gig files, and
resource cleanup at abort for you. If you need features buffile hasn't
got, let me know.)
> ... it must be delayed more to build a multibackend
> test driver. Hiroshi's report showed, that especially
> referential integrity tests don't make much sense if run by a
> single backend serialized.
Clearly a good thing for testing referential integrity, but is it needed
to verify that old functionality still works?
OTOH, such a testbed would also be nice for stress-testing the table
locking and SI changes, so maybe it is critical for 6.6 anyway.
> From my point of view, we could start BETA for a 6.6.6 when I
> have the temp file buffered queue and the multibackend driver
> plus a test suite ready. Even if I don't like it, personally.
Would 1 Feb be a good target date for you? How much would doing things
this way distort your development path, compared to what you'd do if
we didn't plan a 6.6 release?
regards, tom lane
> From my point of view, we could start BETA for a 6.6.6 when I
> have the temp file buffered queue and the multibackend driver
> plus a test suite ready.
If y'all need some help to get the FK stuff farther along, a 6.6
release will help on that imho. It takes the immediate pressure off of
the other developers, and they can choose to continue with their
developments or to take a breather and help out the 6.6 release.
The fact that more work needs to be done on FKs etc to enable a 6.6
release is not fatal; that is an issue for every release on one topic
or another.
I haven't heard anything (yet) which would be a show stopper imho, and
I'd *really* like to decouple some of the changes coming up. In
particular, I could commit "join syntax" for 6.6, and then work on the
query tree redesign for 7.0...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California