On 2016-07-29 15:04, D'Arcy J.M. Cain wrote:
> On Fri, 29 Jul 2016 15:07:53 -0400
> Bruce Momjian <bruce@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?
Data Directory naming, as well as keeping the init-scripts straight.
--
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 214-642-9640 E-Mail: ler@lerctr.org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281