On Wed, Oct 29, 2003 at 12:19:11AM +0000, Oliver Elphick wrote: > This is to get round problems with upgrading major versions, and to > allow people to have multiple database clusters, possibly at different > software versions. ] This is a major problem for Red Hat and Debian, because a dump and ] reload is not required by every upgrade and by the time the need for a ] dump is realised, the old software may be deleted. Debian has certain ] rather unreliable procedures to save the old software and use it to do ] a dump, but these procedures often go wrong. Maybe I'm just missing something obvious, but why don't you do a database dump on prerm upgrade, and a database restore on postinst configure? At prerm upgrade time you have the new package's version and the old package's binaries, so it shouldn't be a problem working out if you need to convert -- either go by major version number, or by encoding the db version as well -- or actually doing it. If the dump fails, you're in a great position to abort the upgrade too -- postgresql is still installed so you can just restart it, and let the admin work out wtf's going on while the old postgresql is still chugging away. Having multiple versions installed might be necessary for some weird sites, but all the extra complexity it involves is a good thing to avoid wherever possible. Cheers, aj -- Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/> I don't speak for anyone save myself. GPG signed mail preferred. Australian DMCA (the Digital Agenda Amendments) Under Review! -- http://azure.humbug.org.au/~aj/blog/copyright/digitalagenda
Attachment:
pgpl8pYjiWDOo.pgp
Description: PGP signature