Luca Longinotti wrote:
The upgrade should actually be possible with PostgreSQL running, as the
blockers are there only to catch a little collision-protect problem (a
binary was moved from postgresql to libpq) and to warn about the pg-hier
USE flag disappearance. Pasting from a forums thread:
"Well, the blocker was added for the simple reason of file-collisions.
With the new libpq/postgresql versions we've moved a file from the
postgresql package to the libpq package. Now, you have to emerge libpq
BEFORE postgresql, so when Portage was installing libpq it would bail
out with a "file collision found, blabla" error. The only way we have of
notifying the user of this is by adding a blocker.
The easiest and most correct way to upgrade would be this:
Code:
FEATURES="-collision-protect" emerge --nodeps libpq
emerge postgresql
The first one basically emerge libpq without checking for blockers and
disables the file-collision check, so that the new libpq will install
correctly, and then you can normally upgrade postgresql itself (which
you MUST do, both really *must* be upgraded!). "
That should work and update your PostgreSQL install correctly.
Yeah, I found that thread last night and followed the instructions. The
emerge went fine, and postgres appeared to restart just fine... but when
I tried to connect I discovered that it wasn't actually running!
Well, long story short, I discovered a stale lock file in /tmp. The
screwy thing was that the init.d script kept saying "ok" even though
postgres wasn't actually running. That's a pretty bad bug, if you ask
me, but I'm not a dev so...
If anyone tries this, watch out for stale postgres lock files... in /tmp
and starting with ".s.blah". I would have had only a few seconds of down
time if I'd known that... and not much more than that if the init script
had done it's job.
b
--
[email protected] mailing list
