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
Not just RPM-based - any distribution who upgrades when the system is
> 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
pgsql-general by date
|Next:||From: Stephan Szabo||Date: 2000-08-29 19:17:54|
|Subject: Re: foreign keys - script|
|Previous:||From: Alfred Perlstein||Date: 2000-08-29 19:15:41|
|Subject: Re: 7.1 Release Date|