Re: 7.1 Release Date

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.