postgres blockage

Calculating world dependencies  .... done!
[blocks B     ] <=dev-db/postgresql-8.0.8 (is blocking
dev-db/libpq-8.0.9)
[ebuild     U ] dev-db/libpq-8.0.9 [8.0.8]
USE="-pg-intdatetime% -threads%"
[ebuild     U ] dev-db/postgresql-8.0.9-r1 [8.0.8]
USE="-test%"

Any ideas how I deal with this on a production postgres
install?

b

-- 
gentoo-servergentoo.org mailing list

On Saturday 16 December 2006 19:10, Ben Munat wrote:
> Calculating world dependencies  .... done!
> [blocks B     ] <=dev-db/postgresql-8.0.8 (is
blocking dev-db/libpq-8.0.9)
> [ebuild     U ] dev-db/libpq-8.0.9 [8.0.8]
USE="-pg-intdatetime% -threads%"
> [ebuild     U ] dev-db/postgresql-8.0.9-r1 [8.0.8]
USE="-test%"
>
> Any ideas how I deal with this on a production postgres
install?

What version of portage are you using? This is (at least)
was fixed in the 
latest version. If I remember correctly, it's fixed in the
latest stable too.

--
Jason Stubbs
-- 
gentoo-servergentoo.org mailing list

I have a script doing emerge --sync every night and I always
update 
portage when I see there's an update. So I should have the
latest stable.

Just went and looked... I have portage-2.1.1-r2.

What does this problem have to do with portage?

thanks for your help,

b

Jason Stubbs wrote:
> On Saturday 16 December 2006 19:10, Ben Munat wrote:
>> Calculating world dependencies  .... done!
>> [blocks B     ] <=dev-db/postgresql-8.0.8 (is
blocking dev-db/libpq-8.0.9)
>> [ebuild     U ] dev-db/libpq-8.0.9 [8.0.8]
USE="-pg-intdatetime% -threads%"
>> [ebuild     U ] dev-db/postgresql-8.0.9-r1 [8.0.8]
USE="-test%"
>>
>> Any ideas how I deal with this on a production
postgres install?
> 
> What version of portage are you using? This is (at
least) was fixed in the 
> latest version. If I remember correctly, it's fixed in
the latest stable too.
> 
> --
> Jason Stubbs
-- 
gentoo-servergentoo.org mailing list

On Saturday 16 December 2006 19:41, Ben Munat wrote:
> I have a script doing emerge --sync every night and I
always update
> portage when I see there's an update. So I should have
the latest stable.
>
> Just went and looked... I have portage-2.1.1-r2.
>
> What does this problem have to do with portage?

On Saturday 16 December 2006 19:10, Ben Munat wrote:
> [blocks B     ] <=dev-db/postgresql-8.0.8 (is
blocking dev-db/libpq-8.0.9) 
> [ebuild     U ] dev-db/libpq-8.0.9 [8.0.8]
USE="-pg-intdatetime% -threads%" 
> [ebuild     U ] dev-db/postgresql-8.0.9-r1 [8.0.8]
USE="-test%"

After both libpq and postgresql have been upgraded, the
block from libpq-8.0.9 
on <=postgresql-8.0.8 is no longer relevant. Recent
versions of portage 
reckognise this and ignore the block. However, it seems that
this has not 
made it to stable yet.

Assuming that above two packages are all that're needed, you
should be able to 
get it around it manually with the following commands.

# emerge --oneshot --nodeps dev-db/libpq
# emerge --oneshot dev-db/postgresql

However, I wouldn't do it while the server is running in
production (even if 
there was no block).

--
Jason Stubbs
-- 
gentoo-servergentoo.org mailing list

WARNING!
I've  broken my database with simply upgrading from 8.0.8 to
8.0.9-r1!

This was due to having "pg-hier"-USE-flag defined,
which patch and
USE-flag was dropped for 8.0.9.
If you have pg-hier set as USE flag you'll have to dump your
database
while still having 8.0.8, then emerge postgresql-8.0.9-r1
and restore
your database from the dump!

Christian


Jason Stubbs schrieb:
> On Saturday 16 December 2006 19:41, Ben Munat wrote:
>> I have a script doing emerge --sync every night and
I always update
>> portage when I see there's an update. So I should
have the latest stable.
>>
>> Just went and looked... I have portage-2.1.1-r2.
>>
>> What does this problem have to do with portage?
> 
> On Saturday 16 December 2006 19:10, Ben Munat wrote:
>> [blocks B     ] <=dev-db/postgresql-8.0.8 (is
blocking dev-db/libpq-8.0.9) 
>> [ebuild     U ] dev-db/libpq-8.0.9 [8.0.8]
USE="-pg-intdatetime% -threads%" 
>> [ebuild     U ] dev-db/postgresql-8.0.9-r1 [8.0.8]
USE="-test%"
> 
> After both libpq and postgresql have been upgraded, the
block from libpq-8.0.9 
> on <=postgresql-8.0.8 is no longer relevant. Recent
versions of portage 
> reckognise this and ignore the block. However, it seems
that this has not 
> made it to stable yet.
> 
> Assuming that above two packages are all that're
needed, you should be able to 
> get it around it manually with the following commands.
> 
> # emerge --oneshot --nodeps dev-db/libpq
> # emerge --oneshot dev-db/postgresql
> 
> However, I wouldn't do it while the server is running
in production (even if 
> there was no block).
> 
> --
> Jason Stubbs

-- 
gentoo-servergentoo.org mailing list

Christian Bricart wrote:
> WARNING!
> I've  broken my database with simply upgrading from
8.0.8 to 8.0.9-r1!
> 
> This was due to having "pg-hier"-USE-flag
defined, which patch and
> USE-flag was dropped for 8.0.9.
> If you have pg-hier set as USE flag you'll have to dump
your database
> while still having 8.0.8, then emerge
postgresql-8.0.9-r1 and restore
> your database from the dump!

You should *always* dump your database and restore it when
upgrading anyway.

Steve
-- 
gentoo-servergentoo.org mailing list

Steve Dibb schrieb:
> Christian Bricart wrote:
>> WARNING!
>> I've  broken my database with simply upgrading from
8.0.8 to 8.0.9-r1!
>>
>> This was due to having "pg-hier"-USE-flag
defined, which patch and
>> USE-flag was dropped for 8.0.9.
>> If you have pg-hier set as USE flag you'll have to
dump your database
>> while still having 8.0.8, then emerge
postgresql-8.0.9-r1 and restore
>> your database from the dump!
> 
> You should *always* dump your database and restore it
when upgrading
> anyway.

true - and done that - but anyway *having* to dump and
restore should
usually not be needed when doing a PostgreSQL update within
a minor
release cycle. From 8.0.x to 8.1.y or 8.2.z that's ok and
needed by
upstream.

But I think that's the reason why portage blocks here on
purpose.

Christian
-- 
gentoo-servergentoo.org mailing list

Jason Stubbs wrote:
> After both libpq and postgresql have been upgraded, the
block from libpq-8.0.9 
> on <=postgresql-8.0.8 is no longer relevant. Recent
versions of portage 
> reckognise this and ignore the block. However, it seems
that this has not 
> made it to stable yet.
> 
> Assuming that above two packages are all that're
needed, you should be able to 
> get it around it manually with the following commands.
> 
> # emerge --oneshot --nodeps dev-db/libpq
> # emerge --oneshot dev-db/postgresql
> 
> However, I wouldn't do it while the server is running
in production (even if 
> there was no block).


Yeah... and that sucks beyond belief. My virtual mail
aliases are stored 
in a postgres db. So, while postgres is being updated, no
one at any of 
my domains gets any mail. Great.

It's days like this when I wonder why I ever bothered with
gentoo.

b
-- 
gentoo-servergentoo.org mailing list

On Sunday 17 December 2006 14:56, Ben Munat wrote:
> Jason Stubbs wrote:
> > However, I wouldn't do it while the server is
running in production (even
> > if there was no block).
>
> Yeah... and that sucks beyond belief. My virtual mail
aliases are stored
> in a postgres db. So, while postgres is being updated,
no one at any of
> my domains gets any mail. Great.
>
> It's days like this when I wonder why I ever bothered
with gentoo.

It's not a Gentoo thing. It's not particularly safe to
upgrade a database 
while in production with any distribution - or on any OS for
that matter. At 
the very least, you should run through what you want to do
on a test system 
and make sure it goes smoothly first.

--
Jason Stubbs
-- 
gentoo-servergentoo.org mailing list

Ben Munat wrote:
> 
> Yeah... and that sucks beyond belief. My virtual mail
aliases are stored 
> in a postgres db. So, while postgres is being updated,
no one at any of 
> my domains gets any mail. Great.
> 
> It's days like this when I wonder why I ever bothered
with gentoo.
> 
> b

Unfortunately this is a Postgres thing and one of the
reasons I 
absolutely hated administrating Postgres. Well maybe a close
second 
after no replication* between different versions.

kashani
* last had to deal with Postgres in 2004, this might be
better in 8.0+
-- 
gentoo-servergentoo.org mailing list