Re: Implement support for TCP_KEEPCNT, TCP_KEEPIDLE, TCP_KEEPINTVL
От | Oliver Jowett |
---|---|
Тема | Re: Implement support for TCP_KEEPCNT, TCP_KEEPIDLE, TCP_KEEPINTVL |
Дата | |
Msg-id | 4320CA2E.1000104@opencloud.com обсуждение исходный текст |
Ответ на | Re: Implement support for TCP_KEEPCNT, TCP_KEEPIDLE, TCP_KEEPINTVL (was Re: [HACKERS] Feature freeze date for 8.1) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Implement support for TCP_KEEPCNT, TCP_KEEPIDLE, TCP_KEEPINTVL (was Re: [HACKERS] Feature freeze date for 8.1)
|
Список | pgsql-patches |
Tom Lane wrote: > Oliver Jowett <oliver@opencloud.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@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
В списке pgsql-patches по дате отправления: