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

Re: Concerns about this release

From: Don Baccus <dhogaza(at)pacifier(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Mitch Vincent <mitch(at)doot(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Concerns about this release
Date: 2001-12-20 01:45:35
Message-ID: 3C2142BF.1070407@pacifier.com (view raw or flat)
Thread:
Lists: pgsql-hackers
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.

-- 
Don Baccus
Portland, OR
http://donb.photo.net, http://birdnotes.net, http://openacs.org


In response to

pgsql-hackers by date

Next:From: Tatsuo IshiiDate: 2001-12-20 01:45:53
Subject: Re: SunOS patch for memcmp()
Previous:From: Christopher Kings-LynneDate: 2001-12-20 01:36:05
Subject: Re: [PATCHES] Problem compiling postgres sql --with-tcl

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