Re: Access Problem After Version Upgrade -- FIXED

Rich Shepard <rshepard(at)appl-ecosys(dot)com> writes:

> On Thu, 26 Jan 2006, Joshua D. Drake wrote:
>
>> Although I am glad you were able to get up and running, typically you don't
>> want to "move" libs like that. Instead update your /etc/ld.so.conf and run
>> ldconfig.
>
> True, Josh. What I'd prefer to do is remove /usr/local/pgsql/ once I know
> that nothing there is being used any more with the 8.x versions of postgres.
> I thought of making softlinks, but those would fail as soon as the directory
> tree was removed.

FWIW, my practice when compiling PG from source (which I usually do)
is as follows:

* Configure each release with '--prefix=/usr/local/pgsql-8.1' (or
whatever)

* Create (as far as disk space permits) independent data directories
for each version--e.g. '/var/lib/pgsql-8.1/data'.

* Symlink whatever version I'm running to '/usr/local/pgsql'. Have
the standard PATH contain '/usr/local/pgsql/bin'.

This way, when I do an upgrade, I can test beforehand by setting PATH
and LD_LIBRARY_PATH (if applicable) appropriately, migrating my data,
running whatever programs I want to test, then switching the symlink.

It's worked fairly well, and it's nice to have the old binaries and
data directory sitting there to switch back to of something breaks
horribly. The problem I've seen with RPM upgrades is that if
something breaks in the data upgrade process, the old binaries are
gone and it's a pain to get back to where you were.

Putting locally-compiled software in /usr/bin or /usr/lib is a bad
idea, generally, as you may confuse your package manager.

-Doug