Thread: 6.5.1 status
We are two weeks after the 6.5 release, and the anticipated problems/patches/porting issues never really materialized. I would suspect that fewer people are using PostgreSQL, but I know that is not true. Seems the two months of beta really got out the bugs. What do people want to do now? Does anyone want to start on 6.6? Do we want to release 6.5.1? Should we relax for a few more weeks and bask in the stable release? I am looking for comments. -- 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 <maillist@candle.pha.pa.us> writes:
> We are two weeks after the 6.5 release, and the anticipated
> problems/patches/porting issues never really materialized.
> I would suspect that fewer people are using PostgreSQL, but I know that
> is not true. Seems the two months of beta really got out the bugs.
I think we did pretty well.
> What do people want to do now? Does anyone want to start on 6.6? Do we
> want to release 6.5.1? Should we relax for a few more weeks and bask in
> the stable release?
IMHO we do need to make a 6.5.1 release --- I know I have a couple of
stupid bugs in 6.5 :-(. But it is not urgent; we could wait another
couple of weeks and see if anything else pops up.
Probably the nearer decision is when to split the tree for 6.6.
Is anyone ready to start on new stuff for 6.6? The argument that
we wanted to avoid double-patching is looking less compelling with
so few patches, so I'm ready to see a tree split as soon as anyone
has anything to commit into 6.6 only...
regards, tom lane
Tom Lane wrote: > > Bruce Momjian <maillist@candle.pha.pa.us> writes: > > We are two weeks after the 6.5 release, and the anticipated > > problems/patches/porting issues never really materialized. > > I would suspect that fewer people are using PostgreSQL, but I know that > > is not true. Seems the two months of beta really got out the bugs. > > I think we did pretty well. First time for last two years -:)). > > What do people want to do now? Does anyone want to start on 6.6? Do we > > want to release 6.5.1? Should we relax for a few more weeks and bask in > > the stable release? > > IMHO we do need to make a 6.5.1 release --- I know I have a couple of > stupid bugs in 6.5 :-(. But it is not urgent; we could wait another > couple of weeks and see if anything else pops up. > > Probably the nearer decision is when to split the tree for 6.6. > Is anyone ready to start on new stuff for 6.6? The argument that > we wanted to avoid double-patching is looking less compelling with > so few patches, so I'm ready to see a tree split as soon as anyone > has anything to commit into 6.6 only... I have nothing yet. But I just made changes to avoid disk writes for read-only transactions (now speed of selects is the same as with -F) - should I put it in 6.5.1 or wait for 6.6? Vadim
> > I think we did pretty well. > > First time for last two years -:)). Yes, Tom, this is not typical for post-release. Your helping certainly contributed to this quietness. > > > > What do people want to do now? Does anyone want to start on 6.6? Do we > > > want to release 6.5.1? Should we relax for a few more weeks and bask in > > > the stable release? > > > > IMHO we do need to make a 6.5.1 release --- I know I have a couple of > > stupid bugs in 6.5 :-(. But it is not urgent; we could wait another > > couple of weeks and see if anything else pops up. > > > > Probably the nearer decision is when to split the tree for 6.6. > > Is anyone ready to start on new stuff for 6.6? The argument that > > we wanted to avoid double-patching is looking less compelling with > > so few patches, so I'm ready to see a tree split as soon as anyone > > has anything to commit into 6.6 only... > > I have nothing yet. But I just made changes to avoid > disk writes for read-only transactions (now speed of > selects is the same as with -F) - should I put it > in 6.5.1 or wait for 6.6? If you are happy with it, would be nice for 6.5.1. Should speed things up very much. -- 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, 29 Jun 1999, Vadim Mikheev wrote:
> Tom Lane wrote:
> >
> > Bruce Momjian <maillist@candle.pha.pa.us> writes:
> > > We are two weeks after the 6.5 release, and the anticipated
> > > problems/patches/porting issues never really materialized.
> > > I would suspect that fewer people are using PostgreSQL, but I know that
> > > is not true. Seems the two months of beta really got out the bugs.
> >
> > I think we did pretty well.
>
> First time for last two years -:)).
We must be starting to know what we are doing, eh? :)
> > > What do people want to do now? Does anyone want to start on 6.6? Do we
> > > want to release 6.5.1? Should we relax for a few more weeks and bask in
> > > the stable release?
> >
> > IMHO we do need to make a 6.5.1 release --- I know I have a couple of
> > stupid bugs in 6.5 :-(. But it is not urgent; we could wait another
> > couple of weeks and see if anything else pops up.
> >
> > Probably the nearer decision is when to split the tree for 6.6.
> > Is anyone ready to start on new stuff for 6.6? The argument that
> > we wanted to avoid double-patching is looking less compelling with
> > so few patches, so I'm ready to see a tree split as soon as anyone
> > has anything to commit into 6.6 only...
>
> I have nothing yet. But I just made changes to avoid
> disk writes for read-only transactions (now speed of
> selects is the same as with -F) - should I put it
> in 6.5.1 or wait for 6.6?
Opinion: if you feel safe, throw it in for v6.5.1.
Let's scheduale a v6.5.1 for July 15th, and a 6.6 split for, let's say,
Monday? That way those that want to can start in on 6.6, but we give a
couple of more weeks to "relax" for those that want to...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
The Hermit Hacker wrote: > > > I have nothing yet. But I just made changes to avoid > > disk writes for read-only transactions (now speed of > > selects is the same as with -F) - should I put it > > in 6.5.1 or wait for 6.6? > > Opinion: if you feel safe, throw it in for v6.5.1. Well, I do. > > Let's scheduale a v6.5.1 for July 15th, and a 6.6 split for, let's say, > Monday? That way those that want to can start in on 6.6, but we give a > couple of more weeks to "relax" for those that want to... Ok for me. Vadim
> > First time for last two years -:)). > > We must be starting to know what we are doing, eh? :) Interesting outlook. :-) > Opinion: if you feel safe, throw it in for v6.5.1. > > Let's scheduale a v6.5.1 for July 15th, and a 6.6 split for, let's say, > Monday? That way those that want to can start in on 6.6, but we give a > couple of more weeks to "relax" for those that want to... Sounds good. -- 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
> > > First time for last two years -:)).
> > We must be starting to know what we are doing, eh? :)
> Interesting outlook. :-)
Hmm. It is also the longest beta, longest period between releases, and
longest slip in release date. Not that those are bad; we apparently
got a solid release out of it.
I still can't believe that Vadim pulled off his huge changes! btw, I
upgraded a small production server at work which does plain-vanilla
SQL stuff and found that the following was *really* all it took to
upgrade from v6.4.2:
pg_dumpall -z > file.pg_dumpall shutdown server change soft link to new tree build and install s/w initdb start new
servercopy pg_hba.conf psql < file.pg_dumpall
About 10 minutes total elapsed time. Pretty impressive imho.
I will have some patches for v6.5.1 (and v6.6, but they may be
superceded during the cycle by Tom Lane's suggestions) to allow the
Postgres packaged apps to be built as shared libraries. The patches
are almost trivial, though the build sequence to actually get
dynamically-linked apps is not.
Also, there is a new version of pgaccess which we could incorporate,
and the ODBC driver could be refreshed. I could also fix a few typos
in the docs...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
> -----Original Message----- > From: owner-pgsql-hackers@postgreSQL.org > [mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Bruce Momjian > Sent: Tuesday, June 29, 1999 11:11 AM > To: PostgreSQL-development > Subject: [HACKERS] 6.5.1 status > > > We are two weeks after the 6.5 release, and the anticipated > problems/patches/porting issues never really materialized. > > I would suspect that fewer people are using PostgreSQL, but I know that > is not true. Seems the two months of beta really got out the bugs. > > What do people want to do now? Does anyone want to start on 6.6? Do we > want to release 6.5.1? Should we relax for a few more weeks and bask in > the stable release? > > I am looking for comments. > I have 2 questions for 6.5.1. 1. Currently we couldn't create an index on numeric type. Is it difficult to add numeric_ops ? 2. I love Oracle TRUNCATE statement. Marcus Mascari [mascarim@yahoo.com] has already implemented this feature,thoughI haven't seen his implementation yet. If his implementation is right,could this new feature be added to 6.5.1 ? Regards. Hiroshi Inoue Inoue@tpf.co.jp
Neither of these two can be added to version 6.5.1...the minor releases
are meant to be 'non-dump/initdb, bug fix only' releases, and, at least
for number 1, adding a numeric_ops would require a dump/reload ...
As for the TRUNCATE, take a look at the oracle_compat.c file in util/adt
and supply a patch that will add the appropriate functionality, and I
don't see why it can't b eadded fo r6.6 ...
On Wed, 30 Jun 1999, Hiroshi Inoue wrote:
>
>
> > -----Original Message-----
> > From: owner-pgsql-hackers@postgreSQL.org
> > [mailto:owner-pgsql-hackers@postgreSQL.org]On Behalf Of Bruce Momjian
> > Sent: Tuesday, June 29, 1999 11:11 AM
> > To: PostgreSQL-development
> > Subject: [HACKERS] 6.5.1 status
> >
> >
> > We are two weeks after the 6.5 release, and the anticipated
> > problems/patches/porting issues never really materialized.
> >
> > I would suspect that fewer people are using PostgreSQL, but I know that
> > is not true. Seems the two months of beta really got out the bugs.
> >
> > What do people want to do now? Does anyone want to start on 6.6? Do we
> > want to release 6.5.1? Should we relax for a few more weeks and bask in
> > the stable release?
> >
> > I am looking for comments.
> >
>
> I have 2 questions for 6.5.1.
>
> 1. Currently we couldn't create an index on numeric type.
> Is it difficult to add numeric_ops ?
>
> 2. I love Oracle TRUNCATE statement.
> Marcus Mascari [mascarim@yahoo.com] has already implemented
> this feature,though I haven't seen his implementation yet.
> If his implementation is right,could this new feature be added to
> 6.5.1 ?
>
> Regards.
>
> Hiroshi Inoue
> Inoue@tpf.co.jp
>
>
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> Neither of these two can be added to version 6.5.1...the minor releases
> are meant to be 'non-dump/initdb, bug fix only' releases, and, at least
> for number 1, adding a numeric_ops would require a dump/reload ...
This could be done as a contrib package for the v6.5.x series. Are you
interested in doing this?
> As for the TRUNCATE, take a look at the oracle_compat.c file in util/adt
> and supply a patch that will add the appropriate functionality, and I
> don't see why it can't b eadded fo r6.6 ...
If TRUNCATE is some "stringy function thing", then that is the place
to look. Isn't it some table deletion short-circuit capability
though?? If so, it is not as trivial...
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
> > > Neither of these two can be added to version 6.5.1...the minor releases > > are meant to be 'non-dump/initdb, bug fix only' releases, and, at least > > for number 1, adding a numeric_ops would require a dump/reload ... > I see. > This could be done as a contrib package for the v6.5.x series. Are you > interested in doing this? > Hmmm,I don't know the right way to do so. AFAIC it is necessary to insert new OID entries into pg_opclass.h and pg_amproc.h . Is it right ? And is it all ? If so,I would try. BTW how do I get new System OID ? > > As for the TRUNCATE, take a look at the oracle_compat.c file in util/adt > > and supply a patch that will add the appropriate functionality, and I > > don't see why it can't b eadded fo r6.6 ... > > If TRUNCATE is some "stringy function thing", then that is the place > to look. Isn't it some table deletion short-circuit capability > though?? If so, it is not as trivial... > TRUNCATE statement deletes all rows of the target table quickly and could not be rollbacked. Marcus Mascari [mascarim@yahoo.com] posted a patch today. At first glance his story seems right,though it needs more checking. Regards. Hiroshi Inoue Inoue@tpf.co.jp
> > This could be done as a contrib package for the v6.5.x series. Are you
> > interested in doing this?
> Hmmm,I don't know the right way to do so.
> AFAIC it is necessary to insert new OID entries into pg_opclass.h and
> pg_amproc.h . Is it right ? And is it all ?
> If so,I would try.
> BTW how do I get new System OID ?
No, you can and should do this using the extensibility features of
Postgres (to make it available in v6.5.x). The docs have an example
dating back to the Chen/Jolly days on how. Look in the Programmer's
Guide in the chapter called "Interfacing Extensions To Indices", which
is also Chapter 36 in the integrated docs.
The other option is to develop patches to the .h files and have them
available when the next full release is out, in ~4-5 months.
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California