Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Open 6.4 items

From: "Marc G(dot) Fournier" <scrappy(at)hub(dot)org>
To: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
Cc: PostgreSQL-development <hackers(at)postgreSQL(dot)org>
Subject: Re: [HACKERS] Open 6.4 items
Date: 1998-10-05 05:28:18
Message-ID: Pine.BSF.4.02.9810050108460.17324-100000@hub.org (view raw or flat)
Thread:
Lists: pgsql-hackers
On Sat, 3 Oct 1998, Bruce Momjian wrote:

> Additions

	Rename as 'release stopper'...

> ------------------
> test new cidr/IP address type(Tom Helbekkmo)
> complete rewrite system changes(Jan)
> notify fixes(Tom)

	These have obviously become show stoppers, since they are now half
implemented, and have to be completed before release.  Do we have ETAs on
this stuff?   As things stand right now, we are looking at November 1st
for a release date on v6.4...a month late, but not much worse then other
releases :)  Unfortunately, because of the lateness for some of this, we
haven't done a solid freeze yet, which means that the testing cycle is
going to be a little bit shorter then we like :(  

	At this time, I'd like to say that the source tree is now
*absolutely* frozen...no more "just one more thing"...the above three
issues will still need work, as they haven't been fully tested, nor do I
believe them to be fully implemented...but, as a result, they can still be
considered to be "bugs", and, as such, code changes can still be
made/submitted to fix those bugs...

> Serious Items
> ------------
> change pg args for platforms that don't support argv changes
> 	(setproctitle()?, sendmail hack?)
> have psql dump out rules text with new function
> man pages/sgml synchronization
> generate html/postscript documentation
> generate postmaster pid file and remove flock/fcntl lock code

	None of these, IMHO, are release stoppers...documentation related
issues don't truly apply to the beta freeze anyway, but unless there is a
real reason that the above coding issues interfere with the ability for
the backend to run on a particular platform, then let's leave them as they
are.  I'm going to look at the setproctitle stuff this week, but will not
be committing any changes until *after* the release, at which time I will
create a seperate patch...

	As for the flock/fcntl lock code...my understanding of it is that
it is only 'startup' related, and doesn't really affect anything...leave
it there for now, create a patch shortly after release that can be used to
remove it if it is causing problems for some...

> CREATE TABLE test (x text, s serial) fails if no database creation permission

	release stopper...please move it up with the other three...

> regression test all platforms

	same as the CREATE TABLE...

> make sure all changes are documented properly

	not included as part of beta freeze, changes here can be made at
any time up till the release date, since it does not affect the running of
the backend...

> Minor items
> -----------
> cnf-ify still can exhaust memory, make SET KSQO more generic
> permissions on indexes:  what do they do?  should it be prevented?
> multi-verion concurrency control - work-in-progress for 6.5
> improve reporting of syntax errors by showing location of error in query
> use index with constants on functions
> allow chaining of pages to allow >8k tuples
> allow multiple generic operators in expressions without the use of parentheses
> document/trigger/rule so changes to pg_shadow create pg_pwd
> large objects orphanage
> improve group handling
> no min/max for oid type
> improve PRIMARY KEY handling

	actually, I'd pretty much say that none of the 'minor' ones are
release stoppers...and, as such, should be moved over to "todo for
v6.5"...
	
	For v6.4, can we just concentrate on, and remove from the list
everything else, the following:

> test new cidr/IP address type(Tom Helbekkmo)
> complete rewrite system changes(Jan)
> notify fixes(Tom)
> CREATE TABLE test (x text, s serial) fails if no database creation permission
> regression test all platforms

	Everything else appears to be a "ya, be nice if we could, but it can
wait" sort of issue...

	If we can get those 5 cleaned up/out, then I think we have a good
release candidate to snapshot and test...
	
Marc G. Fournier                               scrappy(at)hub(dot)org
Systems Administrator @ hub.org                    
scrappy(at){postgresql|isc}.org                       ICQ#7615664


In response to

pgsql-hackers by date

Next:From: Billy G. AllieDate: 1998-10-05 05:31:49
Subject: Re: [HACKERS] plpgsql is not ready for prime time
Previous:From: Billy G. AllieDate: 1998-10-05 05:22:38
Subject: Problem dumping PL/pgsql functions.

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group