Re: [COMMITTERS] pgsql: Add GUC variables to control keep-alive
От | Oliver Jowett |
---|---|
Тема | Re: [COMMITTERS] pgsql: Add GUC variables to control keep-alive |
Дата | |
Msg-id | 42ED95D9.8000203@opencloud.com обсуждение исходный текст |
Ответ на | Re: [COMMITTERS] pgsql: Add GUC variables to control keep-alive (Andrew - Supernews <andrew+nonews@supernews.com>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: