Thread: Re: [COMMITTERS] pgsql: Add GUC variables to control keep-alive times
Rocco Altier wrote: > This broke the build on AIX. > > AIX does not have SOL_TCP as a defined symbol in any of the system > header files. > OK, is there any way of setting the keepalive values on AIX? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
Bruce Momjian wrote: >Rocco Altier wrote: > > >>This broke the build on AIX. >> >>AIX does not have SOL_TCP as a defined symbol in any of the system >>header files. >> >> >> > >OK, is there any way of setting the keepalive values on AIX? > > > Looks like Unixware is broken too, cheers andrew
Andrew Dunstan wrote: > > Looks like Unixware is broken too, > > cheers > > andrew > I think Tom's fix to use IPPROTO_TCP will fix firefly. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 3535 Gaspar Drive, Dallas, TX 75220-3611 US
Larry Rosenman wrote: > I think Tom's fix to use IPPROTO_TCP will fix firefly. Ah, I forgot about the "we'll just use IP protocol numbers as socket option levels" behaviour (BSD-derived?). My Linux man page only talks about SOL_TCP, but I have run into this before and should have remembered.. my bad. per my linux/socket.h: > /* Setsockoptions(2) level. Thanks to BSD these must match IPPROTO_xxx */ > #define SOL_IP 0 > /* #define SOL_ICMP 1 No-no-no! Due to Linux :-) we cannot use SOL_ICMP=1 */ > #define SOL_TCP 6 (I won't get into why using wire-level-protocol constants for syscall option numbering is a bad idea.. :) -O
Larry Rosenman wrote: > > I think Tom's fix to use IPPROTO_TCP will fix firefly. > > LER And based on the last run, it did. Thanks, Tom! -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: ler@lerctr.org US Mail: 3535 Gaspar Drive, Dallas, TX 75220-3611 US
Oliver Jowett <oliver@opencloud.com> writes:
> per my linux/socket.h:
>> /* Setsockoptions(2) level. Thanks to BSD these must match IPPROTO_xxx */
>> #define SOL_IP 0
>> /* #define SOL_ICMP 1 No-no-no! Due to Linux :-) we cannot use SOL_ICMP=1 */
>> #define SOL_TCP 6
> (I won't get into why using wire-level-protocol constants for syscall
> option numbering is a bad idea.. :)
[ raised eyebrow... ] You think the wire protocol numbers are more
likely to change than the syscall assignments? Consider the range of
systems that each change would affect.
Also, that assignment is not mere BSD-ism, it's specified by the Single
Unix Spec, as well as every other document I could lay my hands on
today. Whoever wrote the comments in linux/socket.h is just
clueless.
regards, tom lane
Tom Lane wrote: > Oliver Jowett <oliver@opencloud.com> writes: > >>per my linux/socket.h: > > >>>/* Setsockoptions(2) level. Thanks to BSD these must match IPPROTO_xxx */ >>>#define SOL_IP 0 >>>/* #define SOL_ICMP 1 No-no-no! Due to Linux :-) we cannot use SOL_ICMP=1 */ >>>#define SOL_TCP 6 > > >>(I won't get into why using wire-level-protocol constants for syscall >>option numbering is a bad idea.. :) > > > [ raised eyebrow... ] You think the wire protocol numbers are more > likely to change than the syscall assignments? Consider the range of > systems that each change would affect. I'm not worried about changing values; I think that representing the "option level" as an IP protocol number, in an interface that encompasses non-IP protocols, is a bad API design decision. If the rule for setsockopt is "pass the IP protocol number as the level argument", then what value should I pass to manipulate, say, X.25-specific settings on an X.25 socket? In practice you use a synthetic value which is outside the range of valid IP protocols. getprotoent() won't know about this value and there's no IPPROTO_ define for it -- just a SOL_ one. So, er, why were you using IP protocol constants as levels again? A clear design would have them as two separate namespaces even if they happened to share values. > Also, that assignment is not mere BSD-ism, it's specified by the Single > Unix Spec, as well as every other document I could lay my hands on > today. Whoever wrote the comments in linux/socket.h is just > clueless. That seems a bit unfair, the comment is accurate (the SOL_* constants do need to match the protocol number assignments for compatibility with code that expects the BSD behaviour) and might even predate SUS. From a portability point of view, it certainly seems better to use IPPROTO_* and I have no problem with doing that. It just grates at a design level. Anyway, this doesn't affect the patch one way or the other, which is why I didn't really want to get into it in the first place.. -O
On 2005-07-31, Oliver Jowett <oliver@opencloud.com> wrote: > I'm not worried about changing values; I think that representing the > "option level" as an IP protocol number, in an interface that > encompasses non-IP protocols, is a bad API design decision. The interpretation of that parameter, if not equal to SOL_SOCKET, is clearly protocol-dependent and therefore driven by the protocol family of the socket. > If the rule for setsockopt is "pass the IP protocol number as the level > argument", then what value should I pass to manipulate, say, > X.25-specific settings on an X.25 socket? The rule is "pass whatever value the socket's protocol family expects". For IP that happens to be an IP protocol number. For other families it is some constant meaningful to that family. > In practice you use a synthetic value which is outside the range of > valid IP protocols. No, you don't. There is no assumption that socket level parameters form a single namespace (with the exception of SOL_SOCKET which is common to all protocol families). > getprotoent() won't know about this value getprotoent() is specific to the INET address family and makes no attempt to pretend to support anything else (if it did, it'd need to take an AF_* parameter to disambiguate between families). >> Also, that assignment is not mere BSD-ism, it's specified by the Single >> Unix Spec, as well as every other document I could lay my hands on >> today. Whoever wrote the comments in linux/socket.h is just >> clueless. > > That seems a bit unfair, the comment is accurate (the SOL_* constants do > need to match the protocol number assignments for compatibility with > code that expects the BSD behaviour) and might even predate SUS. It's based on a fundamental misunderstanding that SOL_* constants other than SOL_SOCKET should even exist and that they form a namespace (which they do not). -- Andrew, Supernews http://www.supernews.com - individual and corporate NNTP services
Andrew - Supernews wrote: > On 2005-07-31, Oliver Jowett <oliver@opencloud.com> wrote: > >>I'm not worried about changing values; I think that representing the >>"option level" as an IP protocol number, in an interface that >>encompasses non-IP protocols, is a bad API design decision. > > The interpretation of that parameter, if not equal to SOL_SOCKET, is > clearly protocol-dependent and therefore driven by the protocol family of > the socket. It's *not* clearly protocol dependent, that's my point about the API not being clearly designed. SUS just says this: >> The level argument specifies the protocol level at which the option >> resides. To set options at the socket level, specify the level argument >> as SOL_SOCKET. To set options at other levels, supply the appropriate >> level identifier for the protocol controlling the option. For example, >> to indicate that an option is interpreted by the TCP (Transport Control >> Protocol), set level to IPPROTO_TCP as defined in the <netinet/in.h> >> header. There's no dependency on socket PF mentioned there, and the obvious reading of that text is that a "level identifier" uniquely identifies the "protocol controlling the option" -- so IPPROTO_TCP unambiguously means "the TCP protocol". Having multiple socket-PF-dependent namespaces which might overlap is just asking for hard-to-find bugs (if you accidentally manage to use the wrong namespace for the socket, you run the risk of getting weird behaviour rather than an error). Still counts as badly designed in my book, sorry. -O
On 2005-08-01, Oliver Jowett <oliver@opencloud.com> wrote: > There's no dependency on socket PF mentioned there, and the obvious > reading of that text is that a "level identifier" uniquely identifies > the "protocol controlling the option" -- so IPPROTO_TCP unambiguously > means "the TCP protocol". You're reading more into the spec than is present. It should be obvious that the existence of, number of and organization of any layers that might happen to exist below the socket layer is entirely dependent on the protocol family. The fact that PF-dependent constants are used for referring to such layers should reinforce this. > Having multiple socket-PF-dependent namespaces which might overlap is > just asking for hard-to-find bugs (if you accidentally manage to use the > wrong namespace for the socket, you run the risk of getting weird > behaviour rather than an error). Think about what happens when you add a brand-new protocol family. -- Andrew, Supernews http://www.supernews.com - individual and corporate NNTP services