v6.4.3 ?

jwieck@debis.com (Jan Wieck) writes:

Now that we are going to start v6.5 BETA, isn't it good to
put out v6.4.3 before the hot time begins?

I'm beginning to agree with Jan about this. I have in fact been
thinking that I wasn't going to be in any big hurry to install 6.5
on my company's mission-critical server, because of the size of the
changes being put in place (MVCC etc). We ran 6.4 in early alpha
stage because we had to --- we were getting bitten by 6.3.2 bugs ---
but 6.4 has been pretty stable for us and so we're probably going
to take a wait-and-see attitude about 6.5.

I don't want to see the Postgres group put a *lot* of time into
maintaining back-rev versions, but when we can easily retrofit an
important bugfix into the prior release we should probably do it.

I do say that back-rev maintenance should be bugfixes only, no
feature upgrades. Adding features would not only be more work,
but it would go against the whole point of the exercise, which is
to provide as stable a release as we possibly can.

The good news is that Postgres is getting used for real,
mission-critical work. Every project should have such problems ;-)

regards, tom lane

3. Test the second bugfix release with the result of step 2
and upgrade production. If the first bugfix release can
stand for a time long enough without further bugs
reported, use that for this step.

4. Follow subsequent bugfix releases if the fixes in them do
or could be expected to happen in the production.

Doing it this way means, that a mission critical installation
will use v6.4.* until some time after we've put out at least
v6.5.1. Thus, we should care about them.

Now I see why you patching against 6.4.

-- 
  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 Sun, 7 Feb 1999, Bruce Momjian wrote:

3. Test the second bugfix release with the result of step 2
and upgrade production. If the first bugfix release can
stand for a time long enough without further bugs
reported, use that for this step.

4. Follow subsequent bugfix releases if the fixes in them do
or could be expected to happen in the production.

Doing it this way means, that a mission critical installation
will use v6.4.* until some time after we've put out at least
v6.5.1. Thus, we should care about them.

Now I see why you patching against 6.4.

The arguments for a v6.4.3 make sense to me...tell me when you wish for
this to be created, and it shall be done :)

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

Doing it this way means, that a mission critical installation
will use v6.4.* until some time after we've put out at least
v6.5.1. Thus, we should care about them.

Now I see why you patching against 6.4.

That's the reason. One of the biggest drawbacks against
Postgres is (for many companies at least), that you can't buy
support.

If we only care a little for the last official release
branch, it'll be much better than any payable support for a
commercial product. Yes, I believe it - we have the power.

I recall some replies to recent problem reports on v6.3.2
where we told "upgrade to v6.4.2" (shame on us). That's
easier said than done, if someone has big applications
breaking on new features.

I know that it isn't true, but these "upgrade to another
release" answers instead of "install bugfix release vX.X.X"
look like we don't care about anyone who really uses
Postgres, not only playing around with it just for fun.
That's the sound of M$.

Patching against v6.4 takes time. It must be done manually
nearly all the time since patches don't apply clean. But it's
the only way to give Postgres a real good reputation.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #

Marc G. Fournier wrote:

On Sun, 7 Feb 1999, Bruce Momjian wrote:

Now I see why you patching against 6.4.

The arguments for a v6.4.3 make sense to me...tell me when you wish for
this to be created, and it shall be done :)

A week or so before we start v6.5 BETA will be enough so I
have the time to build the v6.4.3 feature patch before having
to respond to v6.5 BETA calls.

Don't remember what's all fixed between v6.4.2 and now.

Does anyone else know about bugs that are still in the REL6_4
branch and could be fixed without adding features?

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #

jwieck@debis.com (Jan Wieck) writes:

Don't remember what's all fixed between v6.4.2 and now.
Does anyone else know about bugs that are still in the REL6_4
branch and could be fixed without adding features?

I just checked in the ". conftest.sh" -> ". ./conftest.sh" fix to
configure, which several people have complained of (6.4.2 fails
if "." is not in your PATH at configure time).

We have to be pretty careful with these back-rev patches, since they
typically aren't going to get much testing in the back version's
CVS tree. So I'm leery of applying anything that hasn't been tested
for a while in the development branch.

For example, the patch I just applied to CURRENT to link libpgtcl.so
with -lcrypt perhaps ought to go into REL6_4 --- but I'm afraid to do
that until we verify that it works on a variety of platforms. It fixes
things on teo's Linux box but I worry that it might actually break things
elsewhere.

regards, tom lane

I will update the stuff in the REL6_4 tree for 6.4.3.

On Sun, 7 Feb 1999, Bruce Momjian wrote:

3. Test the second bugfix release with the result of step 2
and upgrade production. If the first bugfix release can
stand for a time long enough without further bugs
reported, use that for this step.

4. Follow subsequent bugfix releases if the fixes in them do
or could be expected to happen in the production.

Doing it this way means, that a mission critical installation
will use v6.4.* until some time after we've put out at least
v6.5.1. Thus, we should care about them.

Now I see why you patching against 6.4.

The arguments for a v6.4.3 make sense to me...tell me when you wish for
this to be created, and it shall be done :)

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

-- 
  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 Sun, Feb 07, 1999 at 05:51:08PM -0500, Tom Lane wrote:

jwieck@debis.com (Jan Wieck) writes:

Don't remember what's all fixed between v6.4.2 and now.
Does anyone else know about bugs that are still in the REL6_4
branch and could be fixed without adding features?

I just checked in the ". conftest.sh" -> ". ./conftest.sh" fix to
configure, which several people have complained of (6.4.2 fails
if "." is not in your PATH at configure time).

We have to be pretty careful with these back-rev patches, since they
typically aren't going to get much testing in the back version's
CVS tree. So I'm leery of applying anything that hasn't been tested
for a while in the development branch.

For example, the patch I just applied to CURRENT to link libpgtcl.so
with -lcrypt perhaps ought to go into REL6_4 --- but I'm afraid to do
that until we verify that it works on a variety of platforms. It fixes
things on teo's Linux box but I worry that it might actually break things
elsewhere.

Just a short note:

-lcrypt is available on glibc 2 systems only.

And yes please release a 6.4.3. As a administrator of some sites which rely on
PostgreSQL heavily I would never use a zero-numbered version. The risk is just
too high and too unforseeable.

An example: Before 6.4, we used a table called "user" without any problems.
Unfortunately, this was not possible in 6.4.x, because it became a reserved
keyword there. Having one release together with maintenance updates minimizes
the risk of getting features you don't want.

--

Regards,

Sascha Schumann |
Consultant | finger sas@schell.de
| for PGP public key

Tom Lane wrote:

We have to be pretty careful with these back-rev patches, since they
typically aren't going to get much testing in the back version's
CVS tree. So I'm leery of applying anything that hasn't been tested
for a while in the development branch.

Over careful! They might rely on new features that aren't
there. So it's better to wait for a v6.4.* based bug report
and fix them by hand instead of appying complete patches that
fix it on the fly.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #

That's the reason. One of the biggest drawbacks against
Postgres is (for many companies at least), that you can't buy
support.

If we only care a little for the last official release
branch, it'll be much better than any payable support for a
commercial product. Yes, I believe it - we have the power.

I recall some replies to recent problem reports on v6.3.2
where we told "upgrade to v6.4.2" (shame on us). That's
easier said than done, if someone has big applications
breaking on new features.

I agree.

-- 
  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 wrote:

On Sun, 7 Feb 1999, Bruce Momjian wrote:

Now I see why you patching against 6.4.

The arguments for a v6.4.3 make sense to me...tell me when you wish for
this to be created, and it shall be done :)

A week or so before we start v6.5 BETA will be enough so I
have the time to build the v6.4.3 feature patch before having
to respond to v6.5 BETA calls.

Don't remember what's all fixed between v6.4.2 and now.

Does anyone else know about bugs that are still in the REL6_4
branch and could be fixed without adding features?

OK. I will make a 6.5 changes list, and you can see what we have. Do
you want to make it as a patch, or a full release with a release number?

-- 
  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

Sascha Schumann <sas@schell.de> writes:

On Sun, Feb 07, 1999 at 05:51:08PM -0500, Tom Lane wrote:

For example, the patch I just applied to CURRENT to link libpgtcl.so
with -lcrypt perhaps ought to go into REL6_4 --- but I'm afraid to do
that until we verify that it works on a variety of platforms.

Just a short note:
-lcrypt is available on glibc 2 systems only.

-lcrypt exists on a variety of systems --- you're showing undue
Linux-centrism here. But what I did was to set up the makefiles
so that -lcrypt is included in the shared library link commands
only if configure found that libcrypt exists. We've done this
for libpq itself since 6.4, and have not heard complaints, so
I'm probably being overly conservative to worry that it might
break the higher-level libraries.

regards, tom lane

On Sun, Feb 07, 1999 at 10:06:03PM +0100, Jan Wieck wrote:

I recall some replies to recent problem reports on v6.3.2
where we told "upgrade to v6.4.2" (shame on us). That's
easier said than done, if someone has big applications
breaking on new features.

Agreed.

I know that it isn't true, but these "upgrade to another
release" answers instead of "install bugfix release vX.X.X"
look like we don't care about anyone who really uses
Postgres, not only playing around with it just for fun.
That's the sound of M$.

And once more I agree.

Patching against v6.4 takes time. It must be done manually
nearly all the time since patches don't apply clean. But it's
the only way to give Postgres a real good reputation.

I like this approach. However, when d we stop maintaining the old version? I
think there are still people using 6.3 who cannot simply upgrade to 6.4. So
do we create 6.3.3 too? Or are there no open bug reports on 6.3 anymore?

Michael
--
Michael Meskes | Go SF 49ers!
Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire!
Tel.: (+49) 2431/72651 | Use Debian GNU/Linux!
Email: Michael.Meskes@gmx.net | Use PostgreSQL!

Hi all

That's the reason. One of the biggest drawbacks against
Postgres is (for many companies at least), that you can't buy
support.

IMHO ...

Well, yes one can, one may just need to look around a bit... and pay
commercial support prices.

Example:
As for my self I feel confident that I could provide such support, having
been using Postgres+ since Postgres 0.95? (3?4 years ago?). I charge
$25/hour, but have been considering going to $30/hour. While I've yet to
get a PostgreSQL specific job, I have had some other Linux based jobs.

I'll bet that there are many people scattered around the globe that can
also provide such support.

Perhaps it might be of benefit to both the PostgreSQL image and
companies considering using PostgreSQL if there where a support team
around the world that could be called on. So, that said, what does every
one think of the idea of maintaining on the PostgreSQL web site a contact
list of "Authorized Support Centers"?

Presto, instant commercial support around the globe.

In addition, some time back there was a lot of talk about how to raise
some money to support PostgreSQL development. Well, what if 2%? 5%? or
so of money earned (related to PostgreSQL) from such official support
centers went back to the PostgreSQL development group (what ever that
is.).

PostgreSQL is one of the top 2 or 3 choices to run on Linux, maybe the 1st
choice. And Linux is now exploding in popularity, both in the home and
in the company (I just came from a job where half the computers where
Linux boxes -- ~40 employees, all with computers.)

So, this means that the need for such support will become acute in the
next year or two, and if PostgreSQL already has such a system in place and
debugged, then that alone could put PostgreSQL way out ahead of all the
other choices.

Just my thoughts on the matter.

Thanks for reading this far,
Have a great day
Terry Mackintosh <terry@terrym.com> http://www.terrym.com
sysadmin/owner I'm excited about life! How about YOU!?

Proudly powered by R H Linux 4.2, Apache 1.3.x, PHP 3.x, PostgreSQL 6.x
-----------------------------------------------------------------------
Only if you know where you're going can you get there.

Terry Mackintosh wrote:

Hi all

That's the reason. One of the biggest drawbacks against
Postgres is (for many companies at least), that you can't buy
support.

IMHO ...

Well, yes one can, one may just need to look around a bit... and pay
commercial support prices.

Example:
As for my self I feel confident that I could provide such support, having
been using Postgres+ since Postgres 0.95? (3?4 years ago?). I charge
$25/hour, but have been considering going to $30/hour. While I've yet to
get a PostgreSQL specific job, I have had some other Linux based jobs.

[...]

Nice idea.

But a word of caution seems appropriate.

Commercial support doesn't mean only that you can hire
someone who takes care about your actual problems with the
product. It also means that there is someone you can bill if
that product caused big damage to you (product warranty).

Commercial support doesn't mean only that you hire someone on
a T/M base (time and material). It also means that you can
sign a support contract with a regular payment and have
written down response- and maximum problem-to-fix times,
escalation levels etc.

For these issues (and there are more) you would need an
assurance in the background (or a big company). But this
requires that you have quality assurance management on top of
the development. And that you have aggreed procedures where
escalation levels from your support activate the core
developers in specified times to solve problems. And it
requires that you have more precise product specifications
telling what the product can and where it's limits are.
Otherwise you wouldn't be able to pay the assurance.

There are already distributions of Linux out where you can
buy commercial support with them. They stay behind the
bleeding edge of development and are offered by companies,
that have their own development team apart from the internet
community.

Looking at how we are organized (or better unorganized), all
this high level commercial support seems far away.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #

Jan,
My company Rakekniven provides professional support
packages for our business line of PostgreSQL servers. But
this is in addition to our servers that we build and test
by hand. In other words, the servers that we warranty
have been thoroughly tested (a generation behind) and are
a combination of hardware/software that we feel comfortable
with. Needless to say we spell out in detail, in the
maintenance contract, what the limitations of the software
are and what actions we are willing to provide to the
customer, including, replacing the server.
But you must also remember that all software companies,
including Microsoft, warrant only the media the software
comes on and take absolutely no responsibility for the
use (damage) that may arise from using the software. Take
a look at one of your professional software licenses and
read it. You will find that according to these licenses
that most commercial software is no better than shareware
(License wise).

That's why, in the licenses, you see these big clauses
that say this software is not suitable for use in Nuclear
Power reactor's, etc... As an example, read one of IBM's
Mainframe License's, IBM only guaranties that the hardware
is free from all major defect's, without defining what those
defect's are. And IBM reserved the right to replace that
hardware at there discretion.

D. Gowin

-----Original Message-----
From: jwieck@debis.com [mailto:jwieck@debis.com]
Sent: Monday, February 08, 1999 9:12 AM
To: terry@terrym.com
Cc: hackers@postgreSQL.org
Subject: Re: Commercial support, was Re: [HACKERS] v6.4.3 ?

Terry Mackintosh wrote:

Hi all

That's the reason. One of the biggest drawbacks against
Postgres is (for many companies at least), that you can't buy
support.

IMHO ...

Well, yes one can, one may just need to look around a bit... and pay
commercial support prices.

Example:
As for my self I feel confident that I could provide such support, having
been using Postgres+ since Postgres 0.95? (3?4 years ago?). I charge
$25/hour, but have been considering going to $30/hour. While I've yet to
get a PostgreSQL specific job, I have had some other Linux based jobs.

[...]

Nice idea.

But a word of caution seems appropriate.

Commercial support doesn't mean only that you can hire
someone who takes care about your actual problems with the
product. It also means that there is someone you can bill if
that product caused big damage to you (product warranty).

Commercial support doesn't mean only that you hire someone on
a T/M base (time and material). It also means that you can
sign a support contract with a regular payment and have
written down response- and maximum problem-to-fix times,
escalation levels etc.

For these issues (and there are more) you would need an
assurance in the background (or a big company). But this
requires that you have quality assurance management on top of
the development. And that you have aggreed procedures where
escalation levels from your support activate the core
developers in specified times to solve problems. And it
requires that you have more precise product specifications
telling what the product can and where it's limits are.
Otherwise you wouldn't be able to pay the assurance.

There are already distributions of Linux out where you can
buy commercial support with them. They stay behind the
bleeding edge of development and are offered by companies,
that have their own development team apart from the internet
community.

Looking at how we are organized (or better unorganized), all
this high level commercial support seems far away.

Jan

--

#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#======================================== jwieck@debis.com (Jan Wieck) #

Jan Wieck wrote:

Terry Mackintosh wrote:

Hi all

That's the reason. One of the biggest drawbacks against
Postgres is (for many companies at least), that you can't buy
support.

IMHO ...

Well, yes one can, one may just need to look around a bit... and pay
commercial support prices.

Example:
As for my self I feel confident that I could provide such support, having
been using Postgres+ since Postgres 0.95? (3?4 years ago?). I charge
$25/hour, but have been considering going to $30/hour. While I've yet to
get a PostgreSQL specific job, I have had some other Linux based jobs.

[...]

Nice idea.

But a word of caution seems appropriate.

Commercial support doesn't mean only that you can hire
someone who takes care about your actual problems with the
product. It also means that there is someone you can bill if
that product caused big damage to you (product warranty).

Commercial support doesn't mean only that you hire someone on
a T/M base (time and material). It also means that you can
sign a support contract with a regular payment and have
written down response- and maximum problem-to-fix times,
escalation levels etc.

Usage decisions also depend on one other MAJOR factor, which Linux has
conquered, but I personally feel that PostGres is still a bit shy on:
reliability. We use PostGres commercially, and quite frankly have a
tough time with it, because of consistent failures with it. Although
the price is right, and we hope to stick with PostGres as it matures
into a more robust product, others would not touch it when you consider
the following reliability problems (admittedly all reported on 6.3):

1. Tables "disappearing" while still listed in the db directory
(but no longer visible from the client)
2. Tables being corrupted (i.e. not selectable, not vacuumable,
not exportable)
3. Vacuum commands that take longer to run after one day of table
updates than if the table was to be dumped and reloaded
(e.g. table with 1.7 million rows, 200,000 rows being updated
each day)
4. An inability to run multiple clients simultaneously without
having the backends choke and kick everybody out (we've had
to implement a lock manager that restricts db access to one
client at a time) (Part of the test suite should be an 8 hour
or so load test that has multiple clients reading/writing
to the same/different tables...might be surprised what you
find)
5. Memory leaks/poor mem management in various components that need
to be worked around (vacuum, insert of existing rec into
uniquely indexed table)

Linux is successful because it is reliable, and because many folks are
WILLING to risk an OS that has the perception of being
unsupported, if once they install it it will run cleanly. However,
anyone using a database for any sort of serious application will
generally have a more stringent set of criteria that they apply to
their selection process. I.e. PostGres is tackling a tougher market
than Linux is tackling, and it will have to be correspondingly more
mature in order to enjoy the same success.

Reword? We would be happier if someone were to iron all the problems
out of postgres that make it unreliable, and not very robust, than
if someone were to provide commercial support (which will NOT fix
the aforementioned problems!)

Thomas
------------------------------------------------------------
Thomas Reinke Tel: (416) 460-7021
Director of Technology Fax: (416) 598-2319
E-Soft Inc. http://www.e-softinc.com

Dan Gowin wrote:

But you must also remember that all software companies,
including Microsoft, warrant only the media the software
comes on and take absolutely no responsibility for the
use (damage) that may arise from using the software. Take
a look at one of your professional software licenses and
read it. You will find that according to these licenses
that most commercial software is no better than shareware
(License wise).

That's not necessarily true. While it is almost always true for
consumer-off-the-shelf software, there is plenty of software that
doesn't fit into that category. Quite a few software companies will
sign support contracts (IBM is one) where they will take responsibility
for damage that may arise from the use of the software. This is also
the case for many industrial software packages. Granted, PostgreSQL
doesn't really fall into any of these categories, but these types of
warratees *do* exist.

--
Nick Bastin - RBB Systems, Inc.
Out hme0, through the Cat5K, Across the ATM backbone, through the
firewall, past the provider, hit the router, down the fiber, off another
router... Nothing but net.

Nick Bastin - RBB Systems, Inc.
Out hme0, through the Cat5K, Across the ATM backbone, through the
firewall, past the provider, hit the router, down the fiber, off another
router... Nothing but net.
Nick,

That's not necessarily true. While it is almost always true for
consumer-off-the-shelf software, there is plenty of software that
doesn't fit into that category. Quite a few software companies will
sign support contracts (IBM is one) where they will take responsibility
for damage that may arise from the use of the software. This is also
the case for many industrial software packages. Granted, PostgreSQL
doesn't really fall into any of these categories, but these types of
warratees *do* exist.

Nick,
I didn't say that those contracts don't exist. But
they are usually in conjunction with some specific application.
For example, Oracle's general license on there database
product's is written in such a way that they cannot be
held accountable for anything a customer may do with there
database. The reason's are simple, Oracle couldn't possibly
come up with all of the possible scenario's that their
general purpose software could fail in.
But, on the flip side, Oracle has an Iron clad warranty
on the use of "Oracle Financials". And you can be assured
what a DBA can and cannot do are very strictly defined within
that contract. And if you violate that contract in any minor
way and "Oracle Financials" has any problem, the lawyer's
will use this as a way out.
As for comparing commercial database software to PostgreSQL
reliability. I had to rebuild a Oracle 7.0 database engine
two weeks ago because it was corrupt. And last week I spent
two days exporting/importing a Oracle 7.3 two tablespaces
because of some corruption of some type. And I did this
after Oracle's tech staff suggested it.
What does all of this mean. Well, Oracle (Commercial)
database packages have some of these same problems that plague
PostgreSQL. The only difference is they are less frequent and
are generally tied to the development cycle. I tend to think
of this as a evolution cycle and Postgres's cycle is on
steroids.

My two cents.
D.

Dan Gowin <DGowin@avantec.net> writes:

What does all of this mean. Well, Oracle (Commercial)
database packages have some of these same problems that plague
PostgreSQL. The only difference is they are less frequent and
are generally tied to the development cycle. I tend to think
of this as a evolution cycle and Postgres's cycle is on
steroids.

That it is.

I think most people see rapid release cycles as part of the success
story for open-source software, so I'm not eager to try to slow down
the cycle. But we do need to consider that many users of Postgres
will be more concerned about stability and reliability than having
the latest whizzy features. Making a commitment to maintain the
prior major release as well as the current one seems like a good
answer.

I see a number of different specific issues that are getting lumped
together under the notion of "commercial support":

1. Personal attention to a particular installation, guaranteed
response to a problem, etc. These are things that can and should
be handled by a distributed network of support consultants as Terry
was suggesting.

2. Bug fixing and feature additions in the supported product. (This
is different from "support" in the sense of correcting an admin's
mistake, figuring out a workaround, or otherwise supporting a specific
installation. I'm thinking about changes that require developer-grade
understanding of the code.) I don't really think we need to do
anything differently here, other than have a higher level of effort on
back-patching prior releases. Like most open-source projects we are
far *better* than commercial practice in this area.

3. Commercial guarantees/warrantees/indemnifications, ie, someone pays
you money if the thing doesn't work for you. I don't think this is
going to happen, at least not for the core Postgres development. Who
in their right mind would warrantee something they didn't have 100%
control over? If there's really a demand for it then probably
companies will offer packages based on back-rev Postgres releases that
they have tested like mad and hired a few programmers specifically to
fix bugs in. (They'd probably want to put it on a back-rev OS,
too...)

We should try to encourage qualified people to become support
consultants to deal with point #1. I don't think this group can
or should do anything about #3 though --- that looks like a splinter
project to me. I don't mind someone else taking it up, but it would
be a distraction from the core development project for us.

regards, tom lane

On Mon, 8 Feb 1999, Michael Meskes wrote:

On Sun, Feb 07, 1999 at 10:06:03PM +0100, Jan Wieck wrote:

I recall some replies to recent problem reports on v6.3.2
where we told "upgrade to v6.4.2" (shame on us). That's
easier said than done, if someone has big applications
breaking on new features.

Agreed.

I know that it isn't true, but these "upgrade to another
release" answers instead of "install bugfix release vX.X.X"
look like we don't care about anyone who really uses
Postgres, not only playing around with it just for fun.
That's the sound of M$.

And once more I agree.

Patching against v6.4 takes time. It must be done manually
nearly all the time since patches don't apply clean. But it's
the only way to give Postgres a real good reputation.

I like this approach. However, when d we stop maintaining the old version? I
think there are still people using 6.3 who cannot simply upgrade to 6.4. So
do we create 6.3.3 too? Or are there no open bug reports on 6.3 anymore?

One version back, in my opinion...v6.5's release kills anythingolder then
v6.4, v6.6's release kills anything older then v6.5, etc...

And, no, we aren't "supporting" v6.3 at this time, since this is a new
thing...

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

I like this approach. However, when d we stop maintaining the old version? I
think there are still people using 6.3 who cannot simply upgrade to 6.4. So
do we create 6.3.3 too? Or are there no open bug reports on 6.3 anymore?

We keep releasing versions until no show-stopper bugs exist.

6.4.* had one on COPY bug that Jan is fixing. The others have
workarounds, and we are so quick at pointing people to these
work-arounds, I don't think they warrant a new release.

We get so many improvements with each release, it is tough to back-patch
those into the tree. At some point, the 6.3.* tree would match the
6.4.* tree.

-- 
  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

We keep releasing versions until no show-stopper bugs exist.
6.4.* had one on COPY bug that Jan is fixing. The others have
workarounds, and we are so quick at pointing people to these
work-arounds, I don't think they warrant a new release.

I posted one or two patches into the /pub/patches directory, and am not
sure whether I bothered installing them into the v6.4.x tree since it
may have been declared dead at that point. Be sure and check (or get a
message from me after I've checked) that they have been applied before
releasing v6.4.3...

- Tom

We keep releasing versions until no show-stopper bugs exist.
6.4.* had one on COPY bug that Jan is fixing. The others have
workarounds, and we are so quick at pointing people to these
work-arounds, I don't think they warrant a new release.

I posted one or two patches into the /pub/patches directory, and am not
sure whether I bothered installing them into the v6.4.x tree since it
may have been declared dead at that point. Be sure and check (or get a
message from me after I've checked) that they have been applied before
releasing v6.4.3...

We can't just do 6.4.2 patches, can we? That would be nice. We getting
near starting beta, and will not have lots of time to test things.

-- 
  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

We can't just do 6.4.2 patches, can we? That would be nice. We
getting near starting beta, and will not have lots of time to test
things.

Personally, I would choose to post patches, since as you point out we
are really focused on v6.5beta. We *still* need a patch convention with
a .../patches/ directory shipped with Postgres, and with routines to
help create and apply the patches.

I would suggest that for the future we create a top level directory
called "patches", and within that directory have two routines, perhaps
CreatePatch, CreatePackage, and ApplyPatch. CreatePatch would create a
subdirectory, look for all .orig files and make separate patch files for
each inside the subdirectory. Type a README and post a tar file of the
subdirectory at ftp://postgresql.org/pub/patches/. On the other end,
ApplyPatch could print the README, prompt for an "OK to continue?", and
apply the specified patches.

If there is already a common package for doing this we could use that of
course.

I might have time to do this for v6.5 unless someone else wants to give
it a shot. I have some code which could form the basis for this (and I
know that Bruce has something in the source tree which he uses but which
imho does not have enough of the features mentioned above; my current
code is lacking some of these also)...

- Tom

"Thomas G. Lockhart" <lockhart@alumni.caltech.edu> writes:

Personally, I would choose to post patches, since as you point out we
are really focused on v6.5beta. We *still* need a patch convention with
a .../patches/ directory shipped with Postgres, and with routines to
help create and apply the patches.

The trouble with maintaining a pile of independent patches is that you
have cross-patch dependencies: patch B fails to apply unless patch A
was previously installed, or applies but fails to work right, etc etc.
Worse, an installation reporting a problem might be running a slightly
different set of patches than anyone else, complicating the diagnosis
substantially.

So, while tossing a patch into a "patches" directory sounds easy,
I fear it will lead to more effort overall, both for developers and
users. It also doesn't advance the goal of creating super-stable
versions for people who have chosen to run a back revision for
reliability reasons.

I think the approach already discussed is better: apply bug fixes
(but not feature additions) to the previous release's CVS branch
whenever practical, and put out a dot-N version every so often.

I would suggest that for the future we create a top level directory
called "patches", and within that directory have two routines, perhaps
CreatePatch, CreatePackage, and ApplyPatch.

This would be worth doing in order to simplify life for people working
on the code --- it'd be easier to package up and mail in a set of
changes, and easier to apply them. But I don't think it's an answer
for back-rev maintenance.

regards, tom lane

"Thomas G. Lockhart" <lockhart@alumni.caltech.edu> writes:

Personally, I would choose to post patches, since as you point out we
are really focused on v6.5beta. We *still* need a patch convention with
a .../patches/ directory shipped with Postgres, and with routines to
help create and apply the patches.

The trouble with maintaining a pile of independent patches is that you
have cross-patch dependencies: patch B fails to apply unless patch A
was previously installed, or applies but fails to work right, etc etc.
Worse, an installation reporting a problem might be running a slightly
different set of patches than anyone else, complicating the diagnosis
substantially.

My optimizer fix will not affect other patches. If we only have a few
patches, they will not bump into each other.

-- 
  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, 9 Feb 1999, Tom Lane wrote:

"Thomas G. Lockhart" <lockhart@alumni.caltech.edu> writes:

Personally, I would choose to post patches, since as you point out we
are really focused on v6.5beta. We *still* need a patch convention with
a .../patches/ directory shipped with Postgres, and with routines to
help create and apply the patches.

The trouble with maintaining a pile of independent patches is that you
have cross-patch dependencies: patch B fails to apply unless patch A
was previously installed, or applies but fails to work right, etc etc.
Worse, an installation reporting a problem might be running a slightly
different set of patches than anyone else, complicating the diagnosis
substantially.

So, while tossing a patch into a "patches" directory sounds easy,
I fear it will lead to more effort overall, both for developers and
users. It also doesn't advance the goal of creating super-stable
versions for people who have chosen to run a back revision for
reliability reasons.

I think the approach already discussed is better: apply bug fixes
(but not feature additions) to the previous release's CVS branch
whenever practical, and put out a dot-N version every so often.

I kinda agree with this one also...as Tom's says, at least ppl can't say
"Patch B broke things", but they didn't apply Patch A, which B's fixes
used features from...

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

I kinda agree with this one also...as Tom's says, at least ppl can't
say "Patch B broke things", but they didn't apply Patch A, which B's
fixes used features from...

*shrug* I don't have a strong feeling about it, and would be happy to
carry along two versions. Especially if one or a few people wanted to
adopt the earlier version to ensure that patches get tested before being
applied and to ensure that builds get tested before release. Over long
periods of time we will accumulate more than a few patches, and there
needs to be some way to ensure the integrity and ongoing testing of the
older tree between releases.

So, are we releasing v6.4.3? If so, when? I'll need to scrub it for
outstanding patches...

- Tom