Re: [ADMIN] postgres 6.2 vacuum

From: Lamar Owen <lowen(at)pari(dot)edu>
To: Shridhar Daithankar <shridhar_daithankar(at)persistent(dot)co(dot)in>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [ADMIN] postgres 6.2 vacuum
Date: 2003-09-26 13:22:26
Message-ID: 200309260922.26323.lowen@pari.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-hackers

On Friday 26 September 2003 02:29, Shridhar Daithankar wrote:
> Well, I am sure there are data corruption bugs fixed between 6.2 and
> current CVS head which would count as large impact in terms of numbers and
> severity.

Indeed there are.

> Its not like oracle upgrade where you have to move the OS, hardware and
> spend a large amount of money. The impact of migration is restricted to
> downtime of servers and cleaning up any applications that depend upon any
> incorrect behaviour supported in past.

This isn't necessarily true. That old of a version of PostgreSQL is probably
running on a quite out-of-date OS -- for instance, if the OS was Red Hat
Linux, then the point at which 6.2.1 was shipped was RHL 5.0. Can you even
compile PostgreSQL 7.3.x on RHL 5.0 or its contemporaries?

I have had this problem, and still, at one client, have a box running
PostgreSQL 6.5.3 because later PostgreSQL's haven't been well tested on RHL
5.2. There is a binary-only closed source app running on the box that won't
run on even a Linux 2.2 kernel, much less a 2.4 kernel. The 5.2 box is
running the latest 2.0.x kernel. That client depends upon behaviors of the
older version of that application that the newer version of that application
doesn't perform. So they are quite literally stuck at 6.5.3. I would love
to get them up to something better, but, it's not at the moment worth enough
to them to do it. When the cost-benefit balance swings to the benefit side,
things will change.

If I could even get the box up to RHL 6.2 I'd be better off, because
PostgreSQL 7.3.x builds and runs well there.
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
1 PARI Drive
Rosman, NC 28772
(828)862-5554
www.pari.edu

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Bruno Wolff III 2003-09-26 13:57:57 Re: table constraints vs column
Previous Message Jodi Kanter 2003-09-26 12:35:54 table constraints vs column

Browse pgsql-hackers by date

  From Date Subject
Next Message Tim McAuley 2003-09-26 14:00:30 Re: sequence's plpgsql
Previous Message Shridhar Daithankar 2003-09-26 12:34:11 Re: [HACKERS] Threads vs Processes