Обсуждение: connecting with libpq interface
I installed postgresql in two places - MacOS X and Ubuntu Linux 7.10. Connections with libpq works fine on OS X, but not on Ubuntu and I can't figure out why. Here's the code: On MacOS X, the Connected!! message is displayed, on Ubuntu 7.10 I get Connect error.
#include </usr/local/pgsql/include/libpq-fe.h>
#include <stdlib.h>
int main(int argc, char *argv[])
{
PGconn *cn;
cn = PQconnectdb("dbname=bdp");
if(PQstatus(cn) != CONNECTION_OK)
printf("Connect error\n");
else
printf("Connected!!\n");
}
I am using libpqxx, which is built on libpq and it gives me this detailed message, so I ran the above test program to determine if it was libpqxx or libpq. Apparently, libpq is not connecting for some reason:
terminate called after throwing an instance of 'pqxx::broken_connection'
what(): could not connect to server: No such file or directory
Is the server running locally and accepting
connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?
the server is running and I can connect to it with psql -p 5432. I have these environment variables set, but I don't see how they could be the problem.
export PGDATA=~/bdp/db
export PGDATABASE=bdp
--
Vincent
Vincent Predoehl <vpredoehl@phoenixwebgroup.com> writes:
> I am using libpqxx, which is built on libpq and it gives me this
> detailed message, so I ran the above test program to determine if it
> was libpqxx or libpq. Apparently, libpq is not connecting for some
> reason:
> terminate called after throwing an instance of 'pqxx::broken_connection'
> what(): could not connect to server: No such file or directory
> Is the server running locally and accepting
> connections on Unix domain socket "/var/run/
> postgresql/.s.PGSQL.5432"?
PQerrorMessage() should give you the same info in your standalone
libpq program.
What I'd wonder is whether the postmaster is using that socket location
or not. The more common location is /tmp/.s.PGSQL.5432. You might have
a problem with having a copy of libpq that has a different default
socket path compiled into it than the postmaster does.
regards, tom lane
On Jul 11, 2008, at 3:05 PM, Tom Lane wrote: > Vincent Predoehl <vpredoehl@phoenixwebgroup.com> writes: >> I am using libpqxx, which is built on libpq and it gives me this >> detailed message, so I ran the above test program to determine if it >> was libpqxx or libpq. Apparently, libpq is not connecting for some >> reason: > >> terminate called after throwing an instance of >> 'pqxx::broken_connection' >> what(): could not connect to server: No such file or directory >> Is the server running locally and accepting >> connections on Unix domain socket "/var/run/ >> postgresql/.s.PGSQL.5432"? > > PQerrorMessage() should give you the same info in your standalone > libpq program. Yes it does: could not connect to server: No such file or directory Is the server running locally and accepting connectionson Unix domain socket "/var/run/ postgresql/.s.PGSQL.5432"? > > What I'd wonder is whether the postmaster is using that socket > location > or not. The more common location is /tmp/.s.PGSQL.5432. You might > have > a problem with having a copy of libpq that has a different default > socket path compiled into it than the postmaster does. > > regards, tom lane Do you know where can I find that in the source code? I used the 8.3.3 source from postgresql.org. I did use apt-get to install the source, but I had trouble with the dev headers when I did that. I noticed some bin files in /usr/local/pgsql/bin hung around after doing apt-get remove, but I'm pretty sure the install that is being used is from the build/install of the 8.3.3 source. -- Vincent
Vincent Predoehl <vpredoehl@phoenixwebgroup.com> writes:
> On Jul 11, 2008, at 3:05 PM, Tom Lane wrote:
>>> could not connect to server: No such file or directory
>>> Is the server running locally and accepting
>>> connections on Unix domain socket "/var/run/
>>> postgresql/.s.PGSQL.5432"?
>>
>> What I'd wonder is whether the postmaster is using that socket
>> location
>> or not. The more common location is /tmp/.s.PGSQL.5432. You might
>> have
>> a problem with having a copy of libpq that has a different default
>> socket path compiled into it than the postmaster does.
> Do you know where can I find that in the source code? I used the
> 8.3.3 source from postgresql.org.
The postgresql.org sources will most certainly default to using /tmp.
What I suspect now is that you have a postmaster that you built from
source, and it's using /tmp (did you look for the socket file to
verify?), but your client program is linking to an Ubuntu-supplied
version of libpq.so that has a nonstandard socket location built in.
You'll need to fool with ldconfig or local equivalent to get the
dynamic linker to select the right copy of libpq.so. Or you could
tell the postmaster to use /var/run/postgresql --- there's a
configuration parameter for that somewhere, IIRC.
regards, tom lane
Tom Lane wrote: > Or you could > tell the postmaster to use /var/run/postgresql --- there's a > configuration parameter for that somewhere, IIRC. In conninfo string, you add "host=/tmp" -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Hi, Vincent Predoehl wrote: >>> terminate called after throwing an instance of 'pqxx::broken_connection' >>> what(): could not connect to server: No such file or directory >>> Is the server running locally and accepting >>> connections on Unix domain socket "/var/run/ >>> postgresql/.s.PGSQL.5432"? >> >> PQerrorMessage() should give you the same info in your standalone >> libpq program. > > Yes it does: > > could not connect to server: No such file or directory > Is the server running locally and accepting > connections on Unix domain socket > "/var/run/postgresql/.s.PGSQL.5432"? Something similar has biten me before as well. I figured it is the Debian packager's decision to put those socket files under /var/run/postgresql/, which is not the Postgres standard. Regards Markus
I finally got around to working on this. Just wanted to let you guys know that dding the host parameter to the connection string took care of the problem … thanks!!
Dealing with the postmaster problem of selecting the correct libpq would probably be better, but would take me more time cause I know little about it.
On Jul 11, 2008, at 4:48 PM, Alvaro Herrera wrote:
Tom Lane wrote:Or you couldtell the postmaster to use /var/run/postgresql --- there's aconfiguration parameter for that somewhere, IIRC.In conninfo string, you add "host=/tmp"--Alvaro Herrera http://www.CommandPrompt.com/PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
Vincent