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 entryLOG: 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