On lör, 2010-11-20 at 18:07 -0500, Bruce Momjian wrote:
The output is as expected:
$ psql -h localhost test
psql: could not connect to server: Connection refused
Is the server running on host localhost (127.0.0.1) and
accepting
TCP/IP connections on
Excerpts from Peter Eisentraut's message of vie nov 26 11:06:24 -0300 2010:
Thanks for working on this. However, the example I posted at the
beginning of this thread now does this:
$ ./psql -p 5 -h localhost
psql: could not connect to server: Connection refused
Is the server
Peter Eisentraut wrote:
On l?r, 2010-11-20 at 18:07 -0500, Bruce Momjian wrote:
The output is as expected:
$ psql -h localhost test
psql: could not connect to server: Connection refused
Is the server running on host localhost (127.0.0.1) and
accepting
Alvaro Herrera wrote:
Excerpts from Peter Eisentraut's message of vie nov 26 11:06:24 -0300 2010:
Thanks for working on this. However, the example I posted at the
beginning of this thread now does this:
$ ./psql -p 5 -h localhost
psql: could not connect to server: Connection
On fre, 2010-11-26 at 11:53 -0500, Bruce Momjian wrote:
OK, I updated the code to always use cur_addr in the code --- let me
know if that doesn't fix it.
Now it's even more wrong:
psql: could not connect to server: Connection refused
Is the server running on host localhost (???) and
Peter Eisentraut wrote:
On fre, 2010-11-26 at 11:53 -0500, Bruce Momjian wrote:
OK, I updated the code to always use cur_addr in the code --- let me
know if that doesn't fix it.
Now it's even more wrong:
psql: could not connect to server: Connection refused
Is the server
On fre, 2010-11-26 at 13:27 -0500, Bruce Momjian wrote:
Peter Eisentraut wrote:
On fre, 2010-11-26 at 11:53 -0500, Bruce Momjian wrote:
OK, I updated the code to always use cur_addr in the code --- let me
know if that doesn't fix it.
Now it's even more wrong:
psql: could not
Peter Eisentraut wrote:
On fre, 2010-11-26 at 13:27 -0500, Bruce Momjian wrote:
Peter Eisentraut wrote:
On fre, 2010-11-26 at 11:53 -0500, Bruce Momjian wrote:
OK, I updated the code to always use cur_addr in the code --- let me
know if that doesn't fix it.
Now it's even more
Bruce Momjian wrote:
Peter Eisentraut wrote:
On fre, 2010-11-26 at 13:27 -0500, Bruce Momjian wrote:
Peter Eisentraut wrote:
On fre, 2010-11-26 at 11:53 -0500, Bruce Momjian wrote:
OK, I updated the code to always use cur_addr in the code --- let me
know if that doesn't fix it.
Bruce Momjian br...@momjian.us writes:
Is :: correct?
I don't think so ... I get this, even sillier, response:
$ psql -h ::1 -p 5433 regression
psql: could not connect to server: Connection refused
Is the server running on host ::1 (::) and accepting
TCP/IP connections on port
I wrote:
Seems like a logic bug in inet_net_ntop_ipv6.
um ... no, it's connectFailureMessage's fault.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
Bruce Momjian wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I assume you are suggesting to use our inet_net_ntop() even if the
system has inet_ntop().
If you're going to have code to do the former, it doesn't seem to be
worth the trouble to also have code that does
Excerpts from Bruce Momjian's message of mié nov 24 19:04:30 -0300 2010:
Bruce Momjian wrote:
OK, we will not call inet_ntop() at all. I moved the CIDR part of
adt/inet_net_ntop.c into adt/inet_cidr_ntop.c, and moved the remaining
net part to /port/inet_net_ntop.c.
Applied.
This broke
Alvaro Herrera wrote:
Excerpts from Bruce Momjian's message of nov 24 19:04:30 -0300 2010:
Bruce Momjian wrote:
OK, we will not call inet_ntop() at all. I moved the CIDR part of
adt/inet_net_ntop.c into adt/inet_cidr_ntop.c, and moved the remaining
net part to /port/inet_net_ntop.c.
bruce wrote:
Alvaro Herrera wrote:
Excerpts from Bruce Momjian's message of nov 24 19:04:30 -0300 2010:
Bruce Momjian wrote:
OK, we will not call inet_ntop() at all. I moved the CIDR part of
adt/inet_net_ntop.c into adt/inet_cidr_ntop.c, and moved the remaining
net part to
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I was wondering that. I am unclear if we need it though --- can we not
assume inet_ntop() exists on all systems? We assumed inet_ntoa() did.
The Single Unix Spec includes inet_ntoa but not inet_ntop.
Of course, the buildfarm
Bruce Momjian br...@momjian.us writes:
I assume you are suggesting to use our inet_net_ntop() even if the
system has inet_ntop().
If you're going to have code to do the former, it doesn't seem to be
worth the trouble to also have code that does the latter ...
regards,
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I assume you are suggesting to use our inet_net_ntop() even if the
system has inet_ntop().
If you're going to have code to do the former, it doesn't seem to be
worth the trouble to also have code that does the latter ...
OK, we will
Excerpts from Bruce Momjian's message of vie nov 19 00:17:59 -0300 2010:
Alvaro Herrera wrote:
Excerpts from Bruce Momjian's message of mi nov 17 13:04:46 -0300 2010:
OK, I doubt we want to add complexity to improve this, so I see our
options as:
o ignore the problem
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Bruce Momjian's message of vie nov 19 00:17:59 -0300 2010:
Alvaro Herrera wrote:
I think we should use inet_ntop where available to print the address.
Good idea because inet_ntop() is thread-safe. Does that work on IPv6?
You
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com writes:
Excerpts from Bruce Momjian's message of vie nov 19 00:17:59 -0300 2010:
Alvaro Herrera wrote:
I think we should use inet_ntop where available to print the address.
Good idea because inet_ntop() is thread-safe. Does
Excerpts from Bruce Momjian's message of vie nov 19 16:43:33 -0300 2010:
Tom Lane wrote:
I get the impression that you guys have forgotten the existence of
src/backend/utils/adt/inet_net_ntop.c
Yeah, that is nice, but we are calling this from libpq, not the backend.
Let me work up a
Alvaro Herrera wrote:
Excerpts from Bruce Momjian's message of vie nov 19 16:43:33 -0300 2010:
Tom Lane wrote:
I get the impression that you guys have forgotten the existence of
src/backend/utils/adt/inet_net_ntop.c
Yeah, that is nice, but we are calling this from libpq, not the
Bruce Momjian br...@momjian.us writes:
I was wondering that. I am unclear if we need it though --- can we not
assume inet_ntop() exists on all systems? We assumed inet_ntoa() did.
The Single Unix Spec includes inet_ntoa but not inet_ntop.
Of course, the buildfarm will tell us.
The
Excerpts from Bruce Momjian's message of mié nov 17 13:04:46 -0300 2010:
OK, I doubt we want to add complexity to improve this, so I see our
options as:
o ignore the problem
o display IPv4/IPv6 labels
o display only an IPv6 label
o something else
I think we should use
Alvaro Herrera wrote:
Excerpts from Bruce Momjian's message of mi?? nov 17 13:04:46 -0300 2010:
OK, I doubt we want to add complexity to improve this, so I see our
options as:
o ignore the problem
o display IPv4/IPv6 labels
o display only an IPv6 label
o
Alvaro Herrera wrote:
Excerpts from Bruce Momjian's message of mi?? nov 17 13:04:46 -0300 2010:
OK, I doubt we want to add complexity to improve this, so I see our
options as:
o ignore the problem
o display IPv4/IPv6 labels
o display only an IPv6 label
o
Alvaro Herrera wrote:
Excerpts from Bruce Momjian's message of s??b nov 13 22:36:31 -0300 2010:
OK, I found out how to get the IP address with the attached patch. The
problem is that only pghost is set, never pghostaddr. I am not even
sure how that would get set for this code because my
Excerpts from Bruce Momjian's message of sáb nov 13 22:36:31 -0300 2010:
OK, I found out how to get the IP address with the attached patch. The
problem is that only pghost is set, never pghostaddr. I am not even
sure how that would get set for this code because my tests show it is
not:
On Fri, Nov 12, 2010 at 15:02, Bruce Momjian br...@momjian.us wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I have developed the attached patch to report whether IPv4 or IPv6 are
being used.
What's the use of that exactly? It doesn't really respond to Peter's
concern, I
Magnus Hagander wrote:
On Fri, Nov 12, 2010 at 15:02, Bruce Momjian br...@momjian.us wrote:
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I have developed the attached patch to report whether IPv4 or IPv6 are
being used.
What's the use of that exactly? ?It doesn't really
Tom Lane wrote:
Bruce Momjian br...@momjian.us writes:
I have developed the attached patch to report whether IPv4 or IPv6 are
being used.
What's the use of that exactly? It doesn't really respond to Peter's
concern, I think.
Peter liked:
And I agree it's not very friendly in this
Peter Eisentraut wrote:
On tor, 2010-10-14 at 07:30 +0200, Magnus Hagander wrote:
And I agree it's not very friendly in this specific case - I
wonder if we should log it as localhost (127.0.0.1) and localhost
(::1) (and similar for any other case that returns more than one
address).
Bruce Momjian br...@momjian.us writes:
I have developed the attached patch to report whether IPv4 or IPv6 are
being used.
What's the use of that exactly? It doesn't really respond to Peter's
concern, I think.
regards, tom lane
--
Sent via pgsql-hackers mailing list
On Wed, Oct 13, 2010 at 21:21, Peter Eisentraut pete...@gmx.net wrote:
This surprised me:
psql -p 5 -h localhost
psql: could not connect to server: Connection refused
Is the server running on host localhost and accepting
TCP/IP connections on port 5?
could not connect
Excerpts from Magnus Hagander's message of jue oct 14 02:30:36 -0300 2010:
And I agree it's not very friendly in this specific case - I
wonder if we should log it as localhost (127.0.0.1) and localhost
(::1) (and similar for any other case that returns more than one
address).
+1
--
Álvaro
On tor, 2010-10-14 at 07:30 +0200, Magnus Hagander wrote:
And I agree it's not very friendly in this specific case - I
wonder if we should log it as localhost (127.0.0.1) and localhost
(::1) (and similar for any other case that returns more than one
address).
That looks good.
--
Sent via
This surprised me:
psql -p 5 -h localhost
psql: could not connect to server: Connection refused
Is the server running on host localhost and accepting
TCP/IP connections on port 5?
could not connect to server: Connection refused
Is the server running on host
38 matches
Mail list logo
