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




Sat, 04 Dec 1999 20:07:31 -0500
Mike Mascari <mascarm@mascari.com>
When is 7.0 going Beta?

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 


Sun, 5 Dec 1999 18:35:10 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] When is 7.0 going Beta?
> 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

Mon, 06 Dec 1999 01:58:50 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: [HACKERS] When is 7.0 going Beta?
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

Mon, 06 Dec 1999 10:33:44 +0700
Vadim Mikheev <vadim@krs.ru>
Re: [HACKERS] When is 7.0 going Beta?
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

Sun, 05 Dec 1999 23:02:26 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] When is 7.0 going Beta? 
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 


Mon, 6 Dec 1999 00:30:02 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] When is 7.0 going Beta? 
> 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, Pennsylvania 19026

Mon, 6 Dec 1999 08:35:27 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] When is 7.0 going Beta?
> 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

Mon, 6 Dec 1999 17:58:35 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] When is 7.0 going Beta?


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 


Mon, 6 Dec 1999 19:21:12 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] When is 7.0 going Beta?
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) #



Tue, 7 Dec 1999 00:47:08 +0100 (MET)
wieck@debis.com (Jan Wieck)
Re: [HACKERS] When is 7.0 going Beta?
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

Mon, 06 Dec 1999 20:10:09 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] When is 7.0 going Beta? 

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 


Mon, 6 Dec 1999 21:57:39 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] When is 7.0 going Beta?
> 
> 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, Pennsylvania 19026

Mon, 6 Dec 1999 22:00:26 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] When is 7.0 going Beta?
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) #



Tue, 7 Dec 1999 04:55:50 +0100 (MET)
wieck@debis.com (Jan Wieck)
Re: [HACKERS] When is 7.0 going Beta?
> 
> 
> 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

Mon, 6 Dec 1999 23:12:30 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] When is 7.0 going Beta?

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 


Tue, 7 Dec 1999 01:04:14 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] When is 7.0 going Beta?
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

Tue, 07 Dec 1999 00:10:04 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] When is 7.0 going Beta? 
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

Tue, 07 Dec 1999 12:28:26 +0700
Vadim Mikheev <vadim@krs.ru>
Re: [HACKERS] When is 7.0 going Beta?
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


Tue, 7 Dec 1999 13:10:55 +0100 (MET)
Peter Eisentraut <e99re41@DoCS.UU.SE>
Re: [HACKERS] When is 7.0 going Beta?
> 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, Pennsylvania 19026

Tue, 7 Dec 1999 07:10:58 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] When is 7.0 going Beta?
> 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, Pennsylvania 19026

Tue, 7 Dec 1999 07:14:56 -0500 (EST)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: [HACKERS] When is 7.0 going Beta?
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


Tue, 7 Dec 1999 13:28:28 +0100 (MET)
Peter Eisentraut <e99re41@DoCS.UU.SE>
Re: [HACKERS] When is 7.0 going Beta?
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


Tue, 7 Dec 1999 09:41:33 -0300
"Sergio A. Kessler" <sak@tribctas.gba.gov.ar>
Re: [HACKERS] When is 7.0 going Beta?
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 


Tue, 7 Dec 1999 09:03:20 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] When is 7.0 going Beta?
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 


Tue, 7 Dec 1999 09:03:48 -0400 (AST)
The Hermit Hacker <scrappy@hub.org>
Re: [HACKERS] When is 7.0 going Beta?
> > 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

Tue, 07 Dec 1999 14:18:29 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: [HACKERS] When is 7.0 going Beta?
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 seen http://www.pop4.net?
        Online Campground Directory    http://www.camping-usa.com
       Online Giftshop Superstore    http://www.cloudninegifts.com
==========================================================================




Tue, 7 Dec 1999 10:23:42 -0500 (EST)
Vince Vielhaber <vev@michvhf.com>
Re: [HACKERS] When is 7.0 going Beta?
> 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

Tue, 07 Dec 1999 15:33:45 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: [HACKERS] When is 7.0 going Beta?
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

Tue, 07 Dec 1999 10:40:54 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] When is 7.0 going Beta? 
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 seen http://www.pop4.net?
        Online Campground Directory    http://www.camping-usa.com
       Online Giftshop Superstore    http://www.cloudninegifts.com
==========================================================================




Tue, 7 Dec 1999 10:50:18 -0500 (EST)
Vince Vielhaber <vev@michvhf.com>
Re: [HACKERS] When is 7.0 going Beta?
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


Tue, 7 Dec 1999 17:35:28 +0100 (MET)
Peter Eisentraut <e99re41@DoCS.UU.SE>
Re: [HACKERS] When is 7.0 going Beta? 
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) #



Tue, 7 Dec 1999 18:15:48 +0100 (MET)
wieck@debis.com (Jan Wieck)
Re: [HACKERS] When is 7.0 going Beta?
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

Tue, 07 Dec 1999 12:40:36 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] When is 7.0 going Beta? 
>     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

Wed, 08 Dec 1999 15:51:50 +0000
Thomas Lockhart <lockhart@alumni.caltech.edu>
Re: [HACKERS] When is 7.0 going Beta?