Re: [PATCHES] Implement support for TCP_KEEPCNT, TCP_KEEPIDLE, TCP_KEEPINTVL (was Re: [HACKERS] Feature freeze date for 8.1)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Oliver Jowett <oliver(at)opencloud(dot)com>
Cc: Merlin Moncure <merlin(dot)moncure(at)rcsonline(dot)com>, pgsql-patches(at)postgresql(dot)org, pgsql-hackers-win32(at)postgresql(dot)org
Subject: Re: [PATCHES] Implement support for TCP_KEEPCNT, TCP_KEEPIDLE, TCP_KEEPINTVL (was Re: [HACKERS] Feature freeze date for 8.1)
Date: 2005-09-08 23:40:15
Message-ID: 26710.1126222815@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers-win32 pgsql-patches

Oliver Jowett <oliver(at)opencloud(dot)com> writes:
> The assumption I'm making is that if the TCP_* values are present at
> compile time, then you can make a setsockopt() call and get a sane error
> code back if there's no support -- rather than a segfault, or having the
> OS spontaneously do weird things to the connection, or anything like
> that. Is that a reasonable thing to assume?

Well, on a sane OS it's reasonable. I dunno about Windows ;-)

One question to ask is whether we should treat the setsockopt failure
as fatal or not. It seems to me that aborting the connection could
reasonably be called an overreaction to a bad parameter setting;
couldn't we just set the GUC variable to zero and keep going?

regards, tom lane

In response to

Responses

Browse pgsql-hackers-win32 by date

  From Date Subject
Next Message Tom Lane 2005-09-08 23:48:00 Re: [PATCHES] Implement support for TCP_KEEPCNT, TCP_KEEPIDLE, TCP_KEEPINTVL
Previous Message Oliver Jowett 2005-09-08 23:33:02 Re: [PATCHES] Implement support for TCP_KEEPCNT, TCP_KEEPIDLE, TCP_KEEPINTVL

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2005-09-08 23:48:00 Re: [PATCHES] Implement support for TCP_KEEPCNT, TCP_KEEPIDLE, TCP_KEEPINTVL
Previous Message Oliver Jowett 2005-09-08 23:33:02 Re: [PATCHES] Implement support for TCP_KEEPCNT, TCP_KEEPIDLE, TCP_KEEPINTVL