Re: SOLVED: help! - how to get postgres 7.3 back
On Sun, 2004-01-11 at 09:27, Paul Morgan wrote:
> I've been following this thread with interest, being a user of postgreql
> 7.3.4 on sarge, as the upgrade will be heading my way soon. I did wonder
> why the postinstall on your first upgrade didn't either do the DB upgrade
> or at least warn you what was about to happen. Yet it did apparently do
> it on the second upgrade. I find that a bit confusing. But at least your
> problem has forewarned me.
The recent upgrade to 7.4.1 has seen problems in the automatic upgrade
which are connected to the manner in which upgrading is done.
It is necessary to run pg_dumpall to make a dump that can be reloaded
into the new version (this applies when changing major versions of PG,
in this case, 7.3 -> 7.4). In order to do this, the 7.3 postmaster must
be running and the 7.3 client may have to be used; but these are in the
old package, which has already been deleted by the time the new postinst
can attempt to do the upgrade. So the binaries are copied to
/var/lib/postgres/dumpall/7.3/ by the prerm of the old packages, but
this is done only if there is no copy already there (this was because we
could end up copying 7.4's binaries there in error). These binaries are
linked to some shared libraries; however, since their being copied into
.../dumpall/7.3/ by an old prerm (of 7.3.1 maybe), the shared library
packages have been upgraded to new versions and the versions required by
those saved binaries are no longer to be found on the system. Thus, the
7.3 dumpall cannot be run, and the whole upgrade fails.
The solution is to ensure that the latest 7.3.x-x is installed (7.3.4-9)
and delete /var/lib/postgres/dumpall/7.3/ before attempting the
upgrade. Then the latest 7.3 binaries, depending on libraries that are
still installed, will be copied into .../dumpall/7.3/ and the upgrade
will work.
It is always wise to have pg_dumpall run before upgrading, but it is not
practicable to put this in the prerm, because it may take a long time or
exhaust disk space. If you do have an up-to-date dump and the upgrade
fails, you can simply delete the database, initdb and reload from the
dump.
--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight, UK http://www.lfix.co.uk/oliver
GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C
========================================
"For the LORD is good; his mercy is everlasting; and
his truth endureth to all generations."
Psalms 100:5
Reply to: