Re: Upgrading: So now you tell me!!?!?

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(at)postgresql(dot)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