PQsetdbLogin() and PQconnectdb() fail on HPUX11i 64 bits with empty servername

From: "Jan van der Weijde" <Jan(dot)van(dot)der(dot)Weijde(at)attachmate(dot)com>
To: <pgsql-interfaces(at)postgresql(dot)org>
Subject: PQsetdbLogin() and PQconnectdb() fail on HPUX11i 64 bits with empty servername
Date: 2006-09-20 12:38:23
Message-ID: 4B9C73D1EB78FE4A81475AE8A553B3C6078025@exch-lei1.attachmate.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-interfaces

Hello all,

I'm using PQsetdbLogin() or PQconnectdb() to connect to a local server
on an 64bits HP system with O/S HPUX11i. The PostgreSQL version is 8.1.4
According to the documentation I can leave out the host specification:

host:
Name of host to connect to. If this begins with a slash, it specifies
Unix-domain communication rather than TCP/IP communication; the value is
the name of the directory in which the socket file is stored. The
default behavior when host is not specified is to connect to a
Unix-domain socket in /tmp (or whatever socket directory was specified
when PostgreSQL was built). On machines without Unix-domain sockets, the
default is to connect to localhost.

However when I do that, the client givers error message:

could not connect to server:
Is the server running locally and accepting
connections on Unix domain socket "/tmp/.s.PGSQL.5432"?

while the postmaster server log the first time:
LOG: getsockname() failed: Invalid argument
and any subsequent time:
LOG: incomplete startup packet

No other socket location was specified when PostgreSQL was built, so
both the client and the server should use /tmp

When I compile the client API as 32 bits code, the error does not occur.
When I do specify localhost or an actual server name both connect
functions succeed.

Can anyone help me?

Thank you,
Jan van der Weijde


Responses

Browse pgsql-interfaces by date

  From Date Subject
Next Message LLC 2006-09-21 03:59:10 Oracle only see's 'postgres' db and no schema's vi HSODBC
Previous Message Jeroen T. Vermeulen 2006-09-19 03:03:04 Re: Progress of asynchronous queries