SEO

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, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

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

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

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


---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

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

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

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


---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

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

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

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

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

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

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

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