freebsd stable - Nov 2013 - svn commit: r232945 - in stable/9: share/man/man4 sys/i386/conf sys/netinet sys/sys

Hey guys, any particular reasons why those options are write-only? Is it
just laziness of the developer or is there any particular fundamental
reason for it being like this. This might be some regression, since at
least some 3rd party software that does getsockopt(), checks its status and
only does setsockopt() if the former completed successfully. Which kinda
makes sense IMHO. The software in question is PostgreSQL here. As a result,
the software may be misbehaving since it detects those options as being
present on the configure stage, but cannot really make any use of them
later on during runtime. Had it not detect those options at the build
stage, it might have used some kind of software protocol workaround (i.e.
sending ping/nop packets) so it in fact might trigger some bugs and whatnot.

We believe it might be the reason for some of our problems here with PG 91
and FreeBSD 92.


> Log:
>   Merge 231025 from head:
>     Add new socket options: TCP_KEEPINIT, TCP_KEEPIDLE, TCP_KEEPINTVL and
>     TCP_KEEPCNT, that allow to control initial timeout, idle time, idle
>     re-send interval and idle send count on a per-socket basis.
>
>     Reviewed by:  andre, bz, lstewart
>
Nov  7 16:04:01 sip-dc postgres[64004]: [13-1] LOG:
getsockopt(TCP_KEEPCNT) failed: Protocol not available
Nov  7 16:04:01 sip-dc postgres[64004]: [14-1] LOG:
getsockopt(TCP_KEEPIDLE) failed: Protocol not available
Nov  7 16:04:01 sip-dc postgres[64004]: [15-1] LOG:
getsockopt(TCP_KEEPINTVL) failed: Protocol not available
Nov  7 16:04:02 sip-dc postgres[64140]: [13-1] LOG:
getsockopt(TCP_KEEPCNT) failed: Protocol not available
Nov  7 16:04:02 sip-dc postgres[64140]: [14-1] LOG:
getsockopt(TCP_KEEPIDLE) failed: Protocol not available
Nov  7 16:04:02 sip-dc postgres[64140]: [15-1] LOG:
getsockopt(TCP_KEEPINTVL) failed: Protocol not available

 -Maxim

On Thu, Nov 07, 2013 at 03:10:27PM -0800, Maxim Sobolev wrote:
M> Hey guys, any particular reasons why those options are write-only? Is it
M> just laziness of the developer or is there any particular fundamental
M> reason for it being like this. This might be some regression, since at
M> least some 3rd party software that does getsockopt(), checks its status
and
M> only does setsockopt() if the former completed successfully. Which kinda
M> makes sense IMHO. The software in question is PostgreSQL here. As a
result,
M> the software may be misbehaving since it detects those options as being
M> present on the configure stage, but cannot really make any use of them
M> later on during runtime. Had it not detect those options at the build
M> stage, it might have used some kind of software protocol workaround (i.e.
M> sending ping/nop packets) so it in fact might trigger some bugs and
whatnot.
M> 
M> We believe it might be the reason for some of our problems here with PG 91
M> and FreeBSD 92.

Can you please try attached patch and report?


-- 
Totus tuus, Glebius.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: tcp_usrreq.c.diff
Type: text/x-diff
Size: 843 bytes
Desc: not available
URL:
<http://lists.freebsd.org/pipermail/freebsd-stable/attachments/20131108/732c2974/attachment.diff>