Re: TCP option assign hook doesn't work well if option not supported - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: TCP option assign hook doesn't work well if option not supported
Date
Msg-id 20191223023550.GC34339@paquier.xyz
Whole thread Raw
In response to TCP option assign hook doesn't work well if option not supported  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
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

pgsql-hackers by date:

Previous
From: "tsunakawa.takay@fujitsu.com"
Date:
Subject: RE: Implementing Incremental View Maintenance
Next
From: Michael Paquier
Date:
Subject: Re: Fetching timeline during recovery