On 2016-07-29 15:06, Larry Rosenman wrote:
On 2016-07-29 15:04, D'Arcy J.M. Cain wrote:
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?
Data Directory naming, as well as keeping the init-scripts straight.
And who gets 5432, and Unix socket naming, it starts to get messy.....
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: ler@xxxxxxxxxx
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
