Re: [HACKERS] Bogus bind() warnings
Tom Lane writes: Actually, I think that that may be expected behavior depending on the vintage of the kernel. Note the following comment in StreamServerPort(): Can we make the warning less misleading if IPV6_V6ONLY does not exist? -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Bogus bind() warnings
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane writes: Actually, I think that that may be expected behavior depending on the vintage of the kernel. Note the following comment in StreamServerPort(): Can we make the warning less misleading if IPV6_V6ONLY does not exist? Possibly. How would you like to phrase it? (And do you want to break the strings freeze at this point?) 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
Re: [HACKERS] Bogus bind() warnings
Peter Eisentraut [EMAIL PROTECTED] writes: When I start up with -i, I get the following log: LOG: could not bind IPv4 socket: Address already in use There is no other postmaster running anywhere. I suspect that this has to do with IPv6. This is a SuSE 8.something machine that is relatively fully IPv6 enabled. Is it possible that that kernel considers binding to an IPv6 port to conflict with binding to the same port number as an IPv4 port? IIRC that was the behavior we once expected would happen, but later found out that most kernels don't (yet?) act that way. The present design of trying to bind to both IPv6 and IPv4 sockets would be unnecessary if the kernels acted more rationally. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Bogus bind() warnings
Tom Lane writes: Is it possible that that kernel considers binding to an IPv6 port to conflict with binding to the same port number as an IPv4 port? I don't understand this business, but if it helps, below is my ifconfig output. eth0 Link encap:Ethernet HWaddr 00:40:F6:74:BE:71 inet6 addr: fe80::240:f6ff:fe74:be71/10 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:440903 errors:0 dropped:0 overruns:0 frame:0 TX packets:301944 errors:5 dropped:0 overruns:0 carrier:3 collisions:0 txqueuelen:100 RX bytes:189774879 (180.9 Mb) TX bytes:64786361 (61.7 Mb) Interrupt:11 Base address:0xd800 eth1 Link encap:Ethernet HWaddr 00:50:22:80:A9:6E inet addr:192.168.100.1 Bcast:192.168.100.255 Mask:255.255.255.0 inet6 addr: fe80::250:22ff:fe80:a96e/10 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:99975 errors:0 dropped:0 overruns:0 frame:0 TX packets:126153 errors:0 dropped:0 overruns:0 carrier:0 collisions:8425 txqueuelen:100 RX bytes:15633278 (14.9 Mb) TX bytes:52753463 (50.3 Mb) Interrupt:9 Base address:0x9000 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:107127 errors:0 dropped:0 overruns:0 frame:0 TX packets:107127 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:20827790 (19.8 Mb) TX bytes:20827790 (19.8 Mb) ppp0 Link encap:Point-to-Point Protocol inet addr:82.82.161.250 P-t-P:145.253.4.3 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1492 Metric:1 RX packets:37103 errors:0 dropped:0 overruns:0 frame:0 TX packets:23882 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:3 RX bytes:4652420 (4.4 Mb) TX bytes:5807647 (5.5 Mb) sit0 Link encap:IPv6-in-IPv4 NOARP MTU:1480 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Bogus bind() warnings
Peter Eisentraut [EMAIL PROTECTED] writes: I don't understand this business, but if it helps, below is my ifconfig output. Hmm, you have a bunch of addresses don't you? It looks like we should have included more information in the report of bind failures, like exactly which address failed. Can you step through StreamServerPort, or perhaps just strace postmaster startup, to observe the sequence of bind() calls? It would be useful to know which addresses have already been bound and which one is failing. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Bogus bind() warnings
Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: When I start up with -i, I get the following log: LOG: could not bind IPv4 socket: Address already in use There is no other postmaster running anywhere. I suspect that this has to do with IPv6. This is a SuSE 8.something machine that is relatively fully IPv6 enabled. Is it possible that that kernel considers binding to an IPv6 port to conflict with binding to the same port number as an IPv4 port? IIRC that was the behavior we once expected would happen, but later found out that most kernels don't (yet?) act that way. The present design of trying to bind to both IPv6 and IPv4 sockets would be unnecessary if the kernels acted more rationally. I have seen this before, and reported it, but can't find the thread right now. On Linux with IP6 enabled, IP4 is tunnelled over IP6 - they *are* the same sockets, AFAIK. Didn't we put in a patch after lengthy discussion that fixes things from a pg_hba.conf POV exactly to handle this (i.e. to match an IP4 address in the file with the corresponding IP6 address: n.n.n.n/x - :::n.n.n.n/96+x )? I also recall someone saying this would change in later versions of Linux. cheers andrew ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Bogus bind() warnings
Is it possible that that kernel considers binding to an IPv6 port to conflict with binding to the same port number as an IPv4 port? Actually, I think that that may be expected behavior depending on the vintage of the kernel. Note the following comment in StreamServerPort(): /* * Note: This might fail on some OS's, like Linux older than * 2.4.21-pre3, that don't have the IPV6_V6ONLY socket option, and * map ipv4 addresses to ipv6.It will show :::ipv4 for all * ipv4 connections. */ regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Bogus bind() warnings
On Thu, Nov 06, 2003 at 03:42:39PM -0500, Tom Lane wrote: Is it possible that that kernel considers binding to an IPv6 port to conflict with binding to the same port number as an IPv4 port? Actually, I think that that may be expected behavior depending on the vintage of the kernel. Note the following comment in StreamServerPort(): /* * Note: This might fail on some OS's, like Linux older than * 2.4.21-pre3, that don't have the IPV6_V6ONLY socket option, and * map ipv4 addresses to ipv6.It will show :::ipv4 for all * ipv4 connections. */ Maybe my comment isn't clear enough ... It fails on Linux in case you first bind the AF_INET6 socket to ::, and then try to bind to AF_INET 0.0.0.0, and don't have the IPV6_V6ONLY options. You have this problem from the moment you enable ipv6 support in your kernel. The real fix is to get a kernel/libc that has the IPV6_V6ONLY socket option. Being unable to bind to the port isn't a problem in case you already got the AF_INET6 one. But maybe it might confuse some users who then think something is wrong. Should we just not give that error message, in case we already binded to AF_INET6 ::? Kurt ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Bogus bind() warnings
Kurt Roeckx [EMAIL PROTECTED] writes: Should we just not give that error message, in case we already binded to AF_INET6 ::? Seems like a cure worse than the disease to me --- it could mask real problems. I suppose we could think about dropping it from LOG to DEBUG1 level, so that it wouldn't appear in a default setup; but I'm not sure I'm for that either. Given the, ahem, wide variety of behaviors that seem to be out there, I think we'd best be happy if we have a v4/v6 implementation that has no problems worse than spurious log messages ... regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Bogus bind() warnings
Tom Lane wrote: Kurt Roeckx [EMAIL PROTECTED] writes: Should we just not give that error message, in case we already binded to AF_INET6 ::? Seems like a cure worse than the disease to me --- it could mask real problems. I suppose we could think about dropping it from LOG to DEBUG1 level, so that it wouldn't appear in a default setup; but I'm not sure I'm for that either. Given the, ahem, wide variety of behaviors that seem to be out there, I think we'd best be happy if we have a v4/v6 implementation that has no problems worse than spurious log messages ... I agree. Things that might be serious problems should not be hidden. Maybe it would be better to add a message that the error might be harmless if you have IPv6 turned on. cheers andrew ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
