[wellylug] postgresql-dump .. catch-22 ?

[Ewen McNeill]

In message <428EFF19.9050605 at paradise.net.nz>, Adam Bogacki writes:
>Hmm .. I seem to have reached a catch-22.  [...]
>> /var/lib/postgres/dumpall/7.2/postmaster: error while loading shared
>> libraries: libssl.so.0.9.6: cannot open shared object file: No such
>> file or directory

You'll want to fix that problem first, ie that your system appears to
need libraries which are no longer installed.

apt-get -f install

should fix up the (apparently) missing packages from a partial upgrade
(check carefully what it wishes to do; it'll sometimes restort to
removing things).  If that doesn't want to install the ssl library,
you'll need to manually install libssl0.9.6.

At that point (give or take any other broken dependencies you've
introduced) should be able to run postgresql-dump, and then upgrade your
on-disk database format from 7.2 (in Debian Woody) to 7.4.8 (in Debian 
Sarge/Sid).  And then you should be able to restart the postmaster.

Significant database upgrades are, unfortunately, non-trivial.  And it's
often easier to simply dump the databases, do the upgrade, and reload
the databases by hand anyway.  IME the "automagic" database upgrades
only sometimes work correctly.  This is not just with postgresql
incidentally, it's pretty much any database.  And it shows all the way
through any product based heavily on a database -- subversion, for
instance, requires a dump and reload to deal with some upgrades, due to
the use of BerkeleyDB internally.

Databases, unlike filesystems for instance, don't seem to regard long
term, on disk, binary compatibility as important.  Dumping and reloading
them for even minor updates is not uncommon.  Just yet another reason
why I'm wary of databases.

Ewen