On Friday 11 April 2003 09:57, bkline@rksystems.com wrote:
> I upgraded one of my RedHat machines from 8.0 to 9.0 and PostgreSQL
> stopped working,
[note: subject changed. There is no 'Red Hat 9.0'. There is, however, a 'Red
Hat Linux 9']
It's in the Release notes (or it should be, as it's been in every Red Hat
Linux release notes since a couple of years ago) that one should do a pg_dump
of all data before upgrading.
> These RPMs no longer support any sort of upgrading process other
> than that documented in the regular documentation. That is, you
> must dump, upgrade, initdb, and restore your data. The 7.2 to 7.3
> migration can be quite difficult, even to the point of requiring
> hand-editing of the dumpfile.
I had a semi-automatic upgrade mechanism for previous versions. Going from
7.2 to 7.3 can be very difficult to automate (see the thread 'Upgrade Rant'
in the archives of HACKERS for more details, and for a look at the
unwillingness of some of the developers to consider supporting better
upgrades). My plan was to be able to provide older releases of PostgreSQL
for newer OS's as they came out. I simply have not had the time to build
7.2.x RPM's for RHL 9 as yet. Sorry.
> Thus, the 7.3 postgresql-server RPM specifically conflicts with
> prior versions. The old server subpackage must be removed first,
> the new package installed, and the data restored from dump.
Unfortunately, due to a bug in RPM itself, this safety mechanism I tried to
implement did not work the way it should. The idea was that the OS upgrade
process should not even do the postgresql-server upgrade. That fell over due
to RPM itself not obeying the conflicts directive for instances of the same
package. ARgh.
> Not the sort of thing I expected from an upgrade of the OS. So now
> I'm faced with a Catch-22 dilemma: I need to dump the data with a
> version of the database which is no longer on the machine.
Been there; done that. Four years ago. This is historical behavior with Red
Hat Linux, since Red Hat 5.1 bumped the version from 5.0's 6.2.1 to 6.3.2.
Then Red Hat 6.0 shipped 6.4.2. And then Red Hat 6.1 shipped PostgreSQL
6.5.... (my first RPMset to make it into the Red Hat distribution). And so
on. This is not unusual. Unfortunately.
> I went back and pulled out my RedHat 8.0 CDs and tried to do a forced
> downgrade of PostgreSQL to 7.2, but that failed because of dependency
> conflicts.
Yes. Thank you Red Hat.
> So I pulled down the sources for 7.2.4, unpacked them, and ran
> ./configure and make. That failed, too, with the following errors:
And this is the bummer.
> 1. A clue on how to get out of this box.
Build 7.2.4 from source or source RPM, using the patch previously posted. OR
wait a few days until I can build 7.2.4 RPM's for RHL9 (which I need anyway
for another project; it will just be a few days, though, before I can get to
it).
> 2. An explanation for why the box is necessary? I mean, it
> would have been nice to have left behind sufficient tools
> to do the dump PostgreSQL is requiring. If they were left
> behind, it would have been nice if they were easier to find.
A partial solution is a fixed version of pg_upgrade, but developer interest in
doing something this useful is nearly nil. (I say 'nearly' because Bruce
Momjian has expressed a little interest in getting it working (and he wrote
it in the first place)).
This issue has been beat to death, on numerous occasions, for several years.
I have gotten into flame mode more than once over the obnoxiousness of our
pseudo-upgrade procedure. Now that a FreeBSD user has reported the same sort
of issue using 'portupgrade' (Finally it's not just an RPM thing! (or a
Debian thing!)) maybe some of the *BSD-using developers will see the need for
a real upgrade process instead of the junk we have now.
So, I took out the kludge I had in the RPMset. I tried to prevent the issue;
that didn't work because the rpm program didn't do what I directed it to do.
And now there are going to be a lot of upset users just like you. All of
which could have been prevented if developers had had a little foresight into
how big of a problem this would become. Especially with the upgrade to 7.3.
7.3 needed robust upgrading. That window of opportunity has been missed.
And it's not something that can be kludged. Designing for upgradability has
to become endemic; handling it on the surface with pg_upgrade, no matter how
good pg_upgrade becomes, is still a kludge. Old data should be readable with
the new backend -- period. The backends must be able to reconstruct what is
needed for a new version -- seamlessly and transparently -- for it to work
properly. And this means that great care and forethought must be exercised
in the development of PostgreSQL. This is not currently being done with an
eye towards upgradability. And upgrades will continue to be royal pains
until all the developers begin caring about this distinctly user issue.
(This conclusion was reached at the end of the last time we beat this nearly
dead horse in the Upgrading Rant thread due to the nature of PostgreSQL's
system catalogs and the extreme extensibility PostgreSQL provides.)
So, unless some things change at fundamental levels, it's going to remain a
problem. The lesson is to always do an ASCII dump before an OS upgrade.
PostgreSQL is not the only program that can be borked in an OS upgrade,
either.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
