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

Re: 7.1 Release Date

From: teg(at)redhat(dot)com (Trond Eivind =?iso-8859-1?q?Glomsr=F8d?=)
To: Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, The Hermit Hacker <scrappy(at)hub(dot)org>, pgsql-general(at)postgresql(dot)org
Subject: Re: 7.1 Release Date
Date: 2000-08-29 19:17:01
Message-ID: xuyaedvx4gi.fsf@hoser.devel.redhat.com (view raw or flat)
Thread:
Lists: pgsql-general
Lamar Owen <lamar(dot)owen(at)wgcr(dot)org> writes:

> And, to answer the questions:  currently, the RPM's have to upgrade the
> way they do due to the fact that they are called during an OS upgrade
> cycle -- if you are running RedHat 6.2 with the 6.5.3-6 PostgreSQL RPM's
> installed, and you upgrade to Pinstripe (the RH 7 public beta), which
> give you 7.0.2 RPM's, the binaries necessary to extract the data from
> PGDATA are going to be wiped away by the upgrade -- currently, they are
> being backed up by the RPM's pre-install script so that an upgrade
> script can then call them into service after the hapless user has
> figured out that PostgreSQL doesn't upgrade smoothly.  This is fine and
> good as long as Pinstripe can run the old binaries -- which might not be
> true for the next dot-oh RedHat upgrade!
> 
> Actually, that is true _now_ is a RedHat 4.x user attempts to upgrade to
> Pinstripe -- correct me if I'm wrong, Trond.

For Red Hat 4.x, that would be true - we don't support the ancient
libc5 anymore (OTOH, we didn't include Postgres95 at the time either).
 
> Note that ANY RPM-based distribution is going to have this same
> problem.

Not just RPM-based - any distribution who upgrades when the system is
offline. 

> Yes, Tom, the RPM-based OS's upgrade procedures are brain-dead.

No, it's not - it's just not making assumptions like "enough space is
present to dump everything somewhere" (if you have a multiGB database,
dumping it to upgrade sounds like a bad idea), "the database server is
running, so I can just dump the data" etc.

> But, it can also be argued that our dump/restore upgrade procedure
> is also brain-dead. 

This is basically "no upgrade path. But you can dump your old data
before upgrading. And you can insert data in the new database".



-- 
Trond Eivind Glomsrød
Red Hat, Inc.

In response to

Responses

pgsql-general by date

Next:From: Stephan SzaboDate: 2000-08-29 19:17:54
Subject: Re: foreign keys - script
Previous:From: Alfred PerlsteinDate: 2000-08-29 19:15:41
Subject: Re: 7.1 Release Date

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