> > Keys to this working: > > 1.) Must not require the old version executable backend. There are a number > > of reasons why this might be, but the biggest is due to the way much > > upgrading works in practice -- the old executables are typically gone by the > > time the new package is installed. > > Oh, that is a problem. We would have to require the old executables.
Could this be solved with packaging? Meaning can postmasters from old versions be packed with a new release strictly for the purpose of upgrading? It is my understanding that the only old executable needed is the postmaster is that correct? Perhaps this also requires adding functionality so that pg_dump can run against a singer user postmaster. Example: When PG 7.3 is released, the RPM / deb / setup.exe include the postmaster binary for v 7.2 (perhaps two or three older versions...). An upgrade script is included that does the automatic dump / restore described eariler in this thread. Effectivly, you are using old versions of the postmaster as your standalone dumper. I think this could sidestep the problem of having to create / test / maintain new version of a dumper or pg_upgrade for every release. By default perhaps the postmaster for the previous version of postgres is included, and postmasters from older versions are distrubuted in separate packages, so if I am still runnig 6.5.3 and I want to upgrade to 7.3, I have do install the 6.5.3 upgrade package. Or perhaps there i one pg_upgrade rpm package that includes every postmaster since 6.4. This would allow the upgrade script to know that it all backends are availble to it depeding on what it finds in PG_VERSION, it also allows the admin to removed them all easily once they are no longer needed. ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org
