Skip site navigation (1) Skip section navigation (2)

Re: [COMMITTERS] pgsql: Add GUC variables to control keep-alive

From: Oliver Jowett <oliver(at)opencloud(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: 'PostgreSQL-development' <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [COMMITTERS] pgsql: Add GUC variables to control keep-alive
Date: 2005-07-31 10:54:25
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-committerspgsql-hackers
Tom Lane wrote:
> Oliver Jowett <oliver(at)opencloud(dot)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..


In response to


pgsql-hackers by date

Next:From: Bruce MomjianDate: 2005-07-31 13:40:18
Subject: Re: Remote administration functionality
Previous:From: Andreas PflugDate: 2005-07-31 09:30:51
Subject: Re: Remote administration functionality

pgsql-committers by date

Next:From: Bruce MomjianDate: 2005-07-31 13:54:52
Subject: pgsql: Suggest syntax: < o Allow postgresql.conf file values to be
Previous:From: Tom LaneDate: 2005-07-31 07:30:47
Subject: Re: [COMMITTERS] pgsql: Add GUC variables to control keep-alive

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group