Re: [PATCHES] Implement support for TCP_KEEPCNT, TCP_KEEPIDLE, TCP_KEEPINTVL

Merlin Moncure wrote:
>>Here's a patch that adds four new GUCs:
>>
>> tcp_keepalives (defaults to on, controls SO_KEEPALIVE)
>> tcp_keepalives_idle (controls TCP_KEEPIDLE)
>> tcp_keepalives_interval (controls TCP_KEEPINTVL)
>> tcp_keepalives_count (controls TCP_KEEPCNT)
>
>
> I just tested this on my windows XP machine running rc1. A default
> configuration reports zeros for the tcp values in a 'show all'.

That usually means that there is no OS-level support for the TCP_*
values. Does Windows actually provide those #defines?

> More
> significantly, if you change a tcp parameter from the default, the
> server rejects connections without a relevant error message :(.

Could you clarify what you mean by "rejects"? Does it accept them and
then close the connection, or does it fail to even accept the TCP
connection?

If the connection gets accepted, I'd expect *something* in the
postmaster logs -- can you check?

> I did some research and the only way to control these parameters is to
> adjust the system registry plus a reboot. (somebody correct me here).
> If that is the case IMO it makes the most sense to have the server fail
> to start if the default parameters are changed.

The problem is that the GUC only makes sense when you have an actual TCP
connection present, so it is only set while establishing a new
connection. If setting the value fails (e.g. the OS rejects the value),
then it's just like any other GUC setup failure during backend startup,
which by the sounds of it makes the whole connection fail. I don't know
if we should ignore failures to set a GUC and continue anyway .. that
sounds dangerous.

I'd expect unix-domain-socket connections to continue to work fine in
the face of a misconfiguration currently.

We could check the "non-zero configuration on an OS that has no support"
case at postmaster boot time, I suppose, but that doesn't help with the
case where there is support but the OS rejects the particular values
you're trying to set.

> Even better would be a stronger test to make sure o/s supports this
> feature.

Well, the code assumes that if the TCP_* constants are present then they
can be used. It seems a bit stupid if Windows defines them but doesn't
support them at all.

-O