Re: Upgrading: So now you tell me!!?!? - Mailing list pgsql-admin
From | Lamar Owen |
---|---|
Subject | Re: Upgrading: So now you tell me!!?!? |
Date | |
Msg-id | 200303271408.59247.lamar.owen@wgcr.org Whole thread Raw |
In response to | Upgrading: So now you tell me!!?!? (Hacksaw <hacksaw@hacksaw.org>) |
Responses |
Re: Upgrading: So now you tell me!!?!?
|
List | pgsql-admin |
On Thursday 27 March 2003 13:17, Hacksaw wrote: > I had an older installation of postgresql, 7.1.3. I got down the packages > for 7.3.2. I looked at a few of the files in the directories where the > packages were kept, and seeing no particular warnings, I ran rpm -Uvh > postgresql*, which ran without a hitch, until I restarted the postmaster. > Then it informed me that I should have dumped the damned database before I > upgraded the binaries. This has been true for over four years. It is an interaction between PostgreSQL's insistence on dump/restore between major versions and RPM's insistence that no user input or output can occur during an rpm invocation. Complain to Jeff Johnson at Red Hat about the RPM issue, and complain to pgsql-hackers@postgresql.org about the lack of a smooth upgrade. Find the 7.1.3 packages you had and reinstall them using rpm -Uvh --oldpackage. Then do a proper dump. > This is like seeing the "Bridge Out" sign at the bottom of the river. It isn't a good idea to blindly upgrade any package ever. Regardless of the normal ease. Things break -- witness the situation with the current Wine and the Red Hat 8.0 glibc security update. Be prepared to back out the upgrade by having the old packages available. > Why didn't the preinstall scripts dump the database? Why doesn't the FAQ or > the README in the download directory mention the required procedure? The preinstall scripts run in a very limited environment. There are things they can't do; reliably dumping a database is one of the things that they are very poor at doing. As to the README, well, that would be my fault. There _is_ a README.rpm-dist file in the RPM itself, and I had previously been putting that file in the download directory. I did not do this for this release. Although, it didn't make much difference when it was in the download directory; I still got all kinds of grief. > If there is going to be a conflict that might require having the old > binaries around, why do the new ones replace the old ones? Argh. The newest RPM's have a specific conflicts: clause against the old version. It is supposed to work (it worked once here, but I can't reproduce). Apparently RPM has a bug in the processing of the conflicts clause where the package conflicts with previous versions of itself. I have been in your shoes. It is not a pleasant place to be. But it's not something the RPM distribution can fix, since it is endemic to PostgreSQL itself to require a dump/initdb/restore cycle that by its nature conflicts with the RPM upgrade scenario. I've tried to kludge around it; the cure was worse than the disease. This is why I got into the mostly thankless position of RPM maintainer. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
pgsql-admin by date: