From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: TCP option assign hook doesn't work well if option not supported |
Date: | 2019-12-23 02:35:50 |
Message-ID: | 20191223023550.GC34339@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2019-12-23 03:36:56 | Re: Fetching timeline during recovery |
Previous Message | tsunakawa.takay@fujitsu.com | 2019-12-23 02:26:09 | RE: Implementing Incremental View Maintenance |