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

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

From: Oliver Jowett <oliver(at)opencloud(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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
Date: 2005-09-08 23:33:02
Message-ID: 4320CA2E.1000104@opencloud.com (view raw or flat)
Thread:
Lists: pgsql-hackers-win32pgsql-patches
Tom Lane wrote:
> Oliver Jowett <oliver(at)opencloud(dot)com> writes:
> 
>>Merlin Moncure wrote:
>>
>>>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.

> In short, if you were assuming that then you'd better fix the code.

Sorry, to clarify: If the TCP_* constants are provided, *and* you
configure the backend to try to use non-default values, then the code
will try the appropriate setsockopt(). If that fails, then the
connection gets dropped.

If you don't change the defaults, it doesn't use setsockopt() at all.

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?

...

There doesn't seem any clean way to test if a particular set of values
specified at runtime is going to work or not -- the only way is to try.
I suppose we could set up a dummy TCP connection on postmaster start and
try that, but..

We could potentially do better in the "no TCP_* support" case, detecting
it on postmaster startup (move the check for NULL port down into the
pqcomm code, and complain about non-zero values even in that case if
there's no support); but that doesn't help the other cases.

If I specify out-of-range values on my Linux box, I get this:

> oliver(at)extrashiny ~ $ pg/8.1-beta1/bin/psql -h localhost template1
> psql: server closed the connection unexpectedly
>         This probably means the server terminated abnormally
>         before or while processing the request.

and in the logs:

> LOG:  setsockopt(TCP_KEEPIDLE) failed: Invalid argument

I'd expect to see something similar in the "TCP_* present but no real
support" case.

-O

In response to

Responses

pgsql-patches by date

Next:From: Tom LaneDate: 2005-09-08 23:40:15
Subject: Re: [PATCHES] Implement support for TCP_KEEPCNT, TCP_KEEPIDLE, TCP_KEEPINTVL (was Re: [HACKERS] Feature freeze date for 8.1)
Previous:From: Tom LaneDate: 2005-09-08 23:20:22
Subject: Re: [PATCHES] Implement support for TCP_KEEPCNT, TCP_KEEPIDLE, TCP_KEEPINTVL (was Re: [HACKERS] Feature freeze date for 8.1)

pgsql-hackers-win32 by date

Next:From: Tom LaneDate: 2005-09-08 23:40:15
Subject: Re: [PATCHES] Implement support for TCP_KEEPCNT, TCP_KEEPIDLE, TCP_KEEPINTVL (was Re: [HACKERS] Feature freeze date for 8.1)
Previous:From: Tom LaneDate: 2005-09-08 23:20:22
Subject: Re: [PATCHES] Implement support for TCP_KEEPCNT, TCP_KEEPIDLE, TCP_KEEPINTVL (was Re: [HACKERS] Feature freeze date for 8.1)

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