Rich Shepard <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend
