On Fri, 29 Jul 2016 15:07:53 -0400 Bruce Momjian <bruce@xxxxxxxxxx> wrote: > > The answer is either chroot or mount and run pg_upgrade on another > > server. If you can afford the downtime you can also delete PG, > > install the new version and run pg_upgrade without modifying the > > existing DB. If it succeeds then replace the directories and > > restart the new version. If it fails then uninstall PG, reinstall > > the older version and restart. Lather, rinse, repeat until it > > upgrades cleanly. > > pg_upgrade needs to run the old and new server binaries as part of its > operation, so that would not work. My mistake. I must have used the chroot idea last time I did an upgrade. I might take a look at the NetBSD package (I'm a developer) to see how hard it would be to allow multiple versions. We do keep all the lib stuff in a separate directory so that part would be relatively simple. We just need to find all the binaries and make the names versioned and add a symlink to the user selected primary version to the bare version of the binary name. Example: - psql.8.3 - psql.9.1 - psql.9.3 - psql ==> psql.9.3 Other than linking to the correct library can you think of any other issues with this? -- D'Arcy J.M. Cain <darcy@xxxxxxxxx> | Democracy is three wolves http://www.druid.net/darcy/ | and a sheep voting on +1 416 788 2246 (DoD#0082) (eNTP) | what's for dinner. IM: darcy@xxxxxxx, VoIP: sip:darcy@xxxxxxxxx -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
