On Jan 22, 2009, at 12:25 PM, Les Mikesell wrote:
Joshua Kramer wrote:
Any major database version upgrade requires the attention of a qualified DBA who knows how to test data and applications against the new DB version, and then dump/upgrade/restore.
For example, PostgreSQL introduced some minor syntactical differences with 8.3. If your application uses the features affected by these changes, it would be impossible to simply 'dump/restore' without some massaging of the data and the application.
PostgreSQL does ship with a dumper, pg_dump. If you have the current version of postmaster, then you use pg_dump to connect to that and dump your data in a version-agnostic format. IMHO, the effort of writing a standalone dumper that can recognize all the old file formats is not worth it, because it is a mistake to delete the old version of postmaster off your system before you've done a dump of the database.
So how do you package such a thing in RPM so it can permit both new and old instances to run simultaneously while you do all of this required testing? I suppose these days virtualbox is an almost-reasonable answer but it just seems wrong to have a system that by design doesn't let you test a new instance before replacing the old one.
Historical note: A long time ago (RHL 5.2 iirc) transparent upgrades of postgres databases was attempted within *.rpm packaging. The result was a total disaster.
Don't attempt the database conversion while upgrading is the moral.
Arrange paths in postgres packaging so that both old <-> new utilities are available when needed. That can most easily be done by including whatever old utilities are needed in the new package so that the conversion can be done after the old -> new upgrade.
Alternatively, one can also attempt multiple installs of postgres side-by-side kinda like kernel packages are done.
hth
73 de Jeff