[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [cobalt-users] [RaQ 4r] - Upgrade Postgres and upgrade php to 4.0.6
- Subject: RE: [cobalt-users] [RaQ 4r] - Upgrade Postgres and upgrade php to 4.0.6
- From: "Clark E. Morgan" <prlhkr@xxxxxxxxxxxxx>
- Date: Mon Nov 5 11:48:08 2001
- List-id: Mailing list for users to share thoughts on Cobalt products. <cobalt-users.list.cobalt.com>
> I did a search for pgsql.so and found it in /usr/lib/apache/php/pgsql.so
> I modified the php.ini file again adding extension=pgsql.so
OK, yeah, sound like you did the right thing so far.
> When I check phpinfo(); I see the pgsql extensions also I get as
> far as the
> log in screen
> But when I try to log in I get what follows.
>
>
> Error
>
> PostgreSQL said: ERROR: Attribute 'datallowconn' not found
Well, Postgres and phppgadmin aint playing nice. My guess would be a version
inconsistency, probably the function (dattallowconn) added to pgsql after
the
release you are running. Again, I'd view you as stuck here; but perhaps
cobalt
would have some specific thoughts. Might also try an archived version of
phppgadmin
tested on your particular version of postgres.
> I haven't loaded php 4.0.6 with GD yet - I'm worried about how it might
> affect what is there at the moment.
> Do you know of any issues around updating to php 4.0.6 with GD?. As you
> said in your post It might very well sort out my problems.
> What I have done above does it seem right to you, or am I on the wrong
> track?
Well I compile all my own stuff to the greatest extent possible, including
php; but I'm on a raq3 that doesn't depend on php for any cobalt
functionality;
unlike the raq4, which it sounds like you have. In your case, I'd guess the
php package is really a safer bet.
In any event, I thiknk they are separate issues. It sounds to me as if you
have php properly setup for pgsql. I'm not a postgres guru; but my next step
would to verify that you can connect to your postgres server with some other
client. Most easily, this would be the one local to the server. work
backwards
from there. If you can in fact connect that way, see what elese postgres may
require and again, check what authenticated users you have/can add, and
check
the pgsql site to see when function datallowconn was added. that sounds like
your best bet right now.
> We decided to go with postgres because we have a very complicated backend
> database structure, we have unnecessary duplication between web databases
> and backend databases, we hope to merge the two in the near future. We
> found MySQL was not strong enough to fulfill these needs, and instead of
> dedicating resources to both databases, we decided to concentrate on just
> one.
Fair enough. Just thought in light of your self-procalimed "newbie-ism" that
it was an interesting choice.
Clark