6.5.1 status

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, Pennsylvania 19026

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, Pennsylvania 19026

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 server
copy 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,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

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