Tom Lane wrote:
> Oliver Jowett <[EMAIL PROTECTED]> 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?
Advertising
There's no real reason why not; currently the code looks like this:
> /* Set default keepalive parameters. This should also catch
> * misconfigurations (non-zero values when socket options aren't
> * supported)
> */
> if (pq_setkeepalivesidle(tcp_keepalives_idle, port) != STATUS_OK)
> return STATUS_ERROR;
>
> if (pq_setkeepalivesinterval(tcp_keepalives_interval, port) != STATUS_OK)
> return STATUS_ERROR;
>
> if (pq_setkeepalivescount(tcp_keepalives_count, port) != STATUS_OK)
> return STATUS_ERROR;
We could just log (already done inside pq_*, IIRC) and continue, instead
of erroring out. It's just the way it is because I personally prefer
misconfigurations to break loudly, so you have to fix them ;-)
-O
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
