Thread: Connecting via localhost pg-8.0.3
I'm not sure to what list this question belongs, but here goes. I've just upgraded from 7.4.7 to 8.0.3. All seems to have upgraded well but I've stumbled across one thing I don't understand. It now seems that I have to include host=localhost in the pg_connect params from a php script, whereas these same scripts without this specification worked with 7.4.7. I get the following error if I omit "host=localhost" : Warning: pg_connect(): Unable to connect to PostgreSQL server: could not connect to server: ¸^@Hv@' Is the server running locally and accepting connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"? in /home/dlb/public_html/test.php on line 2 I notice that it appears from the above that without the host specification, the server name comes across as garbage. Again, adding the host specification eliminates the error. In my postgresql.conf file, I have the line: listen_addresses = '*' the php manual says that you need the '-i' option, but from the 8.0- docs, it states that the -i option is deprecated and the above line takes care of it. This is no show-stopper, just a matter of editing a few lines in my php files, but I'm just wondering if it's a config parameter on my part or a change in postgres' default behavior. My php (4.3.10) hasn't been upgraded for some time, so it shouldn't be in php.
David <dbree@duo-county.com> writes:
> I've just upgraded from 7.4.7 to 8.0.3.
On what platform, and how did you build or obtain each of these PG
versions?
> I get the following error if I omit "host=localhost" :
> Warning: pg_connect(): Unable to connect to PostgreSQL server: could
> not connect to server: �^@Hv@' Is the server running locally and
> accepting connections on Unix domain socket
> "/var/run/postgresql/.s.PGSQL.5432"? in
> /home/dlb/public_html/test.php
> on line 2
The junk text where a kernel error message ought to be is a known
problem with some older RPM distributions (if running in a non-C
locale) but I thought it was fixed in all known 8.0.3 packagings.
So I'm a tad interested to find where your 8.0.3 came from.
As far as actually solving your problem: it's a good guess that
the problem is a confusion about where the Postgres server socket
lives. The error message shows that the client library is looking
in /var/run/postgresql/, but the normal default for this is /tmp/.
Do you see a socket file at /tmp/.s.PGSQL.5432 ? If so then you
have a libpq.so that came from a different build than the server
came from, and the ultimate answer is to get those two components
in sync.
It could well be that both of the above points are explained if
your PHP is linking to an old version of libpq.so that doesn't
match your PG server.
regards, tom lane
On Tue, Jun 14, 2005 at 11:22:34PM -0400, Tom Lane wrote:
> David <dbree@duo-county.com> writes:
> > I've just upgraded from 7.4.7 to 8.0.3.
>
> On what platform, and how did you build or obtain each of these PG
> versions?
Oops - thought I included that but apparently didn't..
Platform is Debian. The packages come from The Debian repositories.
> > I get the following error if I omit "host=localhost" :
>
> > Warning: pg_connect(): Unable to connect to PostgreSQL server: could
> > not connect to server: ¸^@Hv@' Is the server running locally and
> > accepting connections on Unix domain socket
> > "/var/run/postgresql/.s.PGSQL.5432"? in
> > /home/dlb/public_html/test.php
> > on line 2
>
> The junk text where a kernel error message ought to be is a known
> problem with some older RPM distributions (if running in a non-C
> locale) but I thought it was fixed in all known 8.0.3 packagings.
> So I'm a tad interested to find where your 8.0.3 came from.
>
> As far as actually solving your problem: it's a good guess that
> the problem is a confusion about where the Postgres server socket
> lives. The error message shows that the client library is looking
> in /var/run/postgresql/, but the normal default for this is /tmp/.
> Do you see a socket file at /tmp/.s.PGSQL.5432 ? If so then you
> have a libpq.so that came from a different build than the server
> came from, and the ultimate answer is to get those two components
> in sync.
Well, you guessed correctly. It was a configuration problem. By
inserting the line:
unix_socket_directory = '/var/run/postgresql'
into postgresql.conf, it works as expected.
I must confess that I was a bit unclear about the connection parameters.
I thought that (in php) "host=localhost" meant to use sockets, but this
means connect through TCP/IP over lo, correct?
> It could well be that both of the above points are explained if
> your PHP is linking to an old version of libpq.so that doesn't
> match your PG server.
I'd wondered if this could have been it, but apparently all appears to
be satisfactory now.
Thanks for the reply. It got me headed in the right direction.
David <dbree@duo-county.com> writes:
> Well, you guessed correctly. It was a configuration problem. By
> inserting the line:
> unix_socket_directory = '/var/run/postgresql'
> into postgresql.conf, it works as expected.
Well, you've still got an issue here somewhere, because if your server
and client libraries came from the same build then they ought to agree
on this without any help from the config file. AFAIK, Debian hasn't
changed their policy about where to put the socket, so it seems like you
must be using a server that didn't come from Debian.
> I must confess that I was a bit unclear about the connection parameters.
> I thought that (in php) "host=localhost" meant to use sockets, but this
> means connect through TCP/IP over lo, correct?
Correct --- "localhost" is an IP-ism referring to TCP loopback
connections. In the Unix-socket world there is no name for the local
machine at all, since that is the whole universe anyway ... all you
need for that is a filesystem pathname.
regards, tom lane
On 6/15/05 11:08 PM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote: Tom, I've been lurking on the pgsql forum for some time, and today I read a reply you had posted, and thought to myself, "He probably has a good idea what is causing my problem", so here it is, if you don't mind taking alook at it... My server is a G4 running OS X Server, and my current workstation is an iMacG5 running OS X 10.4.1 I do my development on the iMacG5, which is a duplicate of the server contents as far as the directory hierarchy is concerned. Once I have stuff working I move a copy to the server. When running in localhost mode on my G5 using something like http://localhost/demo/show_items.php $server_address = $_SERVER['SERVER_ADDR'] ; returns "::1" function ShowArray($aArray) { echo "<pre>" ; print_r($aArray) ; echo "</pre>" ; return ; } ShowArray($_SERVER) ; shows : HTTP_USER_AGENT Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/412 (KHTML, like Gecko) Safari/412 SERVER_SOFTWARE Apache/2.0.52 (Unix) DAV/2 PHP/5.0.4 HTTP_HOST localhost SERVER_NAME localhost SERVER_ADDR ::1 REMOTE_ADDR ::1 If I run the same page on my workstation, and access the page from the server via the fully_qualified_domain, the http://fully_qualified_domain/demo/show_items.php ShowArray($_SERVER) ; shows : SERVER_SOFTWARE Apache/1.3.33 (Darwin) DAV/1.0.3 mod_ssl/2.8.22 OpenSSL/0.9.7b LittleDutchMoose/v10.3(Build 2A82) PHP/4.3.10 mod_perl/1.26 HTTP_HOST www.my_domain_name.com SERVER_NAME www.my_domain_name.com SERVER_ADDR 192.168.1.47 REMOTE_ADDR 64.166.143.xxx NetInfo shows : machines -> localhost -> 127.0.0.1 I have no clue where the "::1" is coming from ? I have several routines that depend on the $_SERVER['SERVER_ADDR'] , and the $_SERVER['REMOTE_ADDR'] Any help would be appreciated... Bill Hernandez Plano, Texas
::1 is a function of the PHP $_SERVER[''] internal function, not a PostgreSQL problem. It will display ::1 on any database, you program a PHP custom function to call the whole IP address. The real question is that a problem in a production environment? Of note, outside IP addresses will display fine using $_SERVER['']. Good Luck, J
Bill Hernandez <pgsql@mac-specialist.com> writes:
> SERVER_ADDR ::1
> REMOTE_ADDR ::1
> I have no clue where the "::1" is coming from ?
Looks perfectly fine to me; that's the usual IPv6 notation for "local
loopback connection", AFAIK. If your client code cannot cope with IPv6
addresses, consider disabling IPv6 in your network preferences.
regards, tom lane
On Thu, Jun 16, 2005 at 12:08:35AM -0400, Tom Lane wrote:
> David <dbree@duo-county.com> writes:
> > Well, you guessed correctly. It was a configuration problem. By
> > inserting the line:
> > unix_socket_directory = '/var/run/postgresql'
> > into postgresql.conf, it works as expected.
>
> Well, you've still got an issue here somewhere, because if your server
> and client libraries came from the same build then they ought to agree
> on this without any help from the config file. AFAIK, Debian hasn't
> changed their policy about where to put the socket, so it seems like you
> must be using a server that didn't come from Debian.
dlb@localhost:~$ apt-cache policy postgresql-8.0
postgresql-8.0:
Installed: 8.0.3-5
Candidate: 8.0.3-5
Version Table:
*** 8.0.3-5 0
90 ftp://ftp.us.debian.org sid/main Packages
100 /var/lib/dpkg/status
There is a bug report at bugs.debian.org/postgresql-8.0 (also in the new
postgresql-common package) relating to the location of the socket. I'd
seen this report before posting my original message, but things didn't
click until I read your reply. Anyway, there was a suggestion by
someone that unix_socket_directory needed to be specified.
I do not know now where where the Debian 7.4 socket was located, as I
had no need to look into that.
From some of the info that came with the package, the structure of the
postgresql packaging system has been changed quite a bit.