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 [EMAIL PROTECTED] 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
