| Doug McNaught 2006-01-26, 4:57 pm |
| Rich Shepard <rshepard@appl-ecosys.com> writes:
> On Thu, 26 Jan 2006, Joshua D. Drake wrote:
>
>
> 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
|