Tom Lane wrote:
> "Mitch Vincent" <mitch(at)doot(dot)org> writes:
>>So if anyone doesn't mind to take a minute, could I get opinions? Is it too
>>paranoid to not use the 7.2 release in production?
> Don is working from the "don't be a pioneer" theory, which is hard to
> dispute in the abstract. In the concrete, though, I see little reason
> to think that 7.2 will be less reliable than 7.1.*, even before we fix
> the inevitable early-return bugs and issue a 7.2.1. We have not made
> any huge changes like WAL in this cycle.
Only on production boxes, though. In practice, Tom's probably right
about the relative reliability but, on the other hand ...
This is really the first release cycle where those of us working on the
OpenACS project feel we have had the luxury of not being early adaptors.
It's a nice feeling for a change and a reflection on PG's maturity.
Our first version of OpenACS was released to run on PG 6.5 beta. 6.4,
which sync'd the log file after every select statement (remember those
days?), just didn't cut it. We also were crashing the backend in 6.4
right-and-left and 6.5 fixed a ton of those. PG 7.0 fixed a bunch of
bugs that were hindering us and we quickly told everyone using our
toolkit to upgrade ASAP. When we inherited the aD code base for what's
now OpenACS 4 and decided to support both Oracle and PG with common
source code, we quickly decided we'd only support PG 7.1, with its outer
joins, even though it was still in a pre-release state.
So ... now I can afford to be conservative and hey, I'm enjoying it!
> You can read those numbers however you want, but to me they look like
> 7.2.0 will be better than 7.1.anything.
None of my sites seem to be affected by any PG 7.1 bug, and as they run
the same stereotyped queries over and over again, I'm not terribly
concerned about suddenly hitting a roadbump.
So while PG 7.2 may have fewer bugs than PG 7.1, it may still introduce
new bugs that will affect me in a negative way. Just because I appear
to be dodging 7.1's bullets doesn't mean I'll dodge new rounds fired by 7.2.
Also fixing bugs may expose accidental dependencies on such bugs. When
we first started moving OpenACS 3.x from 6.5 to 7.0 we found a few
illegal queries that had slipped through 6.5, appearing to work, which
triggered explicit errors in PG 7.0.
So testing first on a development box isn't just a protection against
any new bugs you introduce. New fixes can lead to work, too, and it's
really nicer to find this out on test, not production, boxes.
http://donb.photo.net, http://birdnotes.net, http://openacs.org
In response to
pgsql-hackers by date
|Next:||From: Tatsuo Ishii||Date: 2001-12-20 01:45:53|
|Subject: Re: SunOS patch for memcmp() |
|Previous:||From: Christopher Kings-Lynne||Date: 2001-12-20 01:36:05|
|Subject: Re: [PATCHES] Problem compiling postgres sql --with-tcl|