|
Home > Archive > PostgreSQL Administration > June 2005 > Connecting via localhost pg-8.0.3
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
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.
---------------------------(end of broadcast)---------------------------
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
| |
| Tom Lane 2005-06-15, 3:24 am |
| 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
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
| |
|
| On Tue, Jun 14, 2005 at 11:22:34PM -0400, Tom Lane wrote:
> David <dbree@duo-county.com> writes:
>
> 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.
>
>
> 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_director
y = '/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.
---------------------------(end of broadcast)---------------------------
TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql
.org
| |
| Tom Lane 2005-06-16, 3:24 am |
| David <dbree@duo-county.com> writes:
> Well, you guessed correctly. It was a configuration problem. By
> inserting the line:
> unix_socket_director
y = '/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
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
| |
|
| On Thu, Jun 16, 2005 at 12:08:35AM -0400, Tom Lane wrote:
> David <dbree@duo-county.com> writes:
>
> 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_director
y 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.
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
|
|
|
|
|