Tom Lane wrote:
> Oliver Jowett <[EMAIL PROTECTED]> 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:
> [EMAIL PROTECTED] ~ $ 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
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
