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