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:
http://www.postgresql.org/mailpref/pgsql-
Bruce Momjian 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 5433?
Seems
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 t
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.
> > >
> > >
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:
> >
> > psq
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 serv
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
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: Con
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
> > accepti
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 ser
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 connec
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
> >
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/in
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.
Th
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian 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 th
Tom Lane wrote:
> Bruce Momjian 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 not call
Bruce Momjian 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
--
Se
Tom Lane wrote:
> Bruce Momjian 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
Bruce Momjian 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 buildfarm unfortunate
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 libp
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
Tom Lane wrote:
> Alvaro Herrera 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 I
Alvaro Herrera 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 indicated that
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 th
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
>
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
>
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 shou
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 bec
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:
Magnus Hagander wrote:
> On Fri, Nov 12, 2010 at 15:02, Bruce Momjian wrote:
> > Tom Lane wrote:
> >> Bruce Momjian 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 Pete
On Fri, Nov 12, 2010 at 15:02, Bruce Momjian wrote:
> Tom Lane wrote:
>> Bruce Momjian 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 li
Tom Lane wrote:
> Bruce Momjian 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 specific cas
Bruce Momjian 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 (pgsql-hackers@p
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
> > addr
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
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
--
Á
On Wed, Oct 13, 2010 at 21:21, Peter Eisentraut 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 to serv
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 "local
38 matches
Mail list logo
