Re: [gentoo-server] postgres blockage

[Ben Munat]

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
-- 
gentoo-server@g.o mailing list