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(at)momjian(dot)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.
>
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(at)lerctr(dot)org
US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281