On Fri, 29 Jul 2016 15:07:53 -0400 Bruce Momjian <br...@momjian.us> 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 <da...@druid.net> | 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: da...@vex.net, VoIP: sip:da...@druid.net -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
