Thread: TCP option assign hook doesn't work well if option not supported

TCP option assign hook doesn't work well if option not supported

From

Peter Eisentraut

Date:

19 December 2019, 21:26:19

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

Re: TCP option assign hook doesn't work well if option not supported

From

Michael Paquier

Date:

23 December 2019, 05:35:50

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

Attachment

signature.asc