Обсуждение: TCP option assign hook doesn't work well if option not supported
macOS does not support the socket option TCP_USER_TIMEOUT. Yet, I can
start a server with postgres -D ... --tcp-user-timeout=100 without a
diagnostic. Only when I connect I get a log entry
LOG: setsockopt(TCP_USER_TIMEOUT) not supported
Perhaps the logic in pq_settcpusertimeout() should be changed like this:
int
pq_settcpusertimeout(int timeout, Port *port)
{
+#ifdef TCP_USER_TIMEOUT
if (port == NULL || IS_AF_UNIX(port->laddr.addr.ss_family))
return STATUS_OK;
-#ifdef TCP_USER_TIMEOUT
if (timeout == port->tcp_user_timeout)
return STATUS_OK;
So that the #else branch that is supposed to check this will also be run
in the postmaster (where port == NULL).
Or perhaps there should be a separate GUC check hook that just does
#ifndef TCP_USER_TIMEOUT
if (val != 0)
return false;
#endif
return true;
The same considerations apply to the various TCP keepalive settings, but
since those are widely supported the unsupported code paths probably
haven't gotten much attention.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
On Thu, Dec 19, 2019 at 07:26:19PM +0100, Peter Eisentraut wrote: > macOS does not support the socket option TCP_USER_TIMEOUT. Yet, I can start > a server with postgres -D ... --tcp-user-timeout=100 without a diagnostic. > Only when I connect I get a log entry > > LOG: setsockopt(TCP_USER_TIMEOUT) not supported Yeah, this choice was made to be consistent with what we have for the other TCP parameters. > So that the #else branch that is supposed to check this will also be run in > the postmaster (where port == NULL). Hm. That would partially revisit cc3bda3. No actual objections from me to generate a LOG when starting the postmaster as that won't be invasive, though I think that it should be done consistently for all the TCP parameters. > Or perhaps there should be a separate GUC check hook that just does > > #ifndef TCP_USER_TIMEOUT > if (val != 0) > return false; > #endif > return true; > > The same considerations apply to the various TCP keepalive settings, but > since those are widely supported the unsupported code paths probably haven't > gotten much attention. Yeah, Windows does not support tcp_keepalives_count for one, so setting it in postgresql.conf generate the same LOG message for each connection attempt. -- Michael