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

2005-07-31 Thread Tom Lane
Oliver Jowett [EMAIL PROTECTED] 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

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

2005-07-31 Thread Oliver Jowett
Tom Lane wrote: Oliver Jowett [EMAIL PROTECTED] 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

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

2005-07-31 Thread Andrew - Supernews
On 2005-07-31, Oliver Jowett [EMAIL PROTECTED] 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

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

2005-07-31 Thread Oliver Jowett
Andrew - Supernews wrote: On 2005-07-31, Oliver Jowett [EMAIL PROTECTED] 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

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

2005-07-31 Thread Andrew - Supernews
On 2005-08-01, Oliver Jowett [EMAIL PROTECTED] 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

Re: [HACKERS] [COMMITTERS] pgsql: Add GUC variables to control keep-alive times for idle, interval,

2005-07-30 Thread Rocco Altier
This broke the build on AIX. AIX does not have SOL_TCP as a defined symbol in any of the system header files. -rocco -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Momjian Sent: Saturday, July 30, 2005 11:17 AM To:

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

2005-07-30 Thread Bruce Momjian
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

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

2005-07-30 Thread Andrew Dunstan
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

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

2005-07-30 Thread Larry Rosenman
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

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

2005-07-30 Thread Oliver Jowett
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

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

2005-07-30 Thread Larry Rosenman
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,