Re: Implement support for TCP_KEEPCNT, TCP_KEEPIDLE, TCP_KEEPINTVL

From: Oliver Jowett <oliver(at)opencloud(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: Implement support for TCP_KEEPCNT, TCP_KEEPIDLE, TCP_KEEPINTVL
Date: 2005-05-26 23:14:37
Message-ID: 4296585D.90504@opencloud.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Tom Lane wrote:
> Oliver Jowett <oliver(at)opencloud(dot)com> writes:
>
>>Here's a patch that adds four new GUCs:
>
>
>> tcp_keepalives (defaults to on, controls SO_KEEPALIVE)
>> tcp_keepalives_idle (controls TCP_KEEPIDLE)
>> tcp_keepalives_interval (controls TCP_KEEPINTVL)
>> tcp_keepalives_count (controls TCP_KEEPCNT)
>
> Do you think the system defaults are really going to be port-specific?

I don't understand what you mean. TCP_* override the system defaults on
a per-connection basis, if that's what you mean.

> I'm slightly annoyed by the number of syscalls this adds to every
> connection startup ... getting rid of redundant getsockopt calls would
> help. Getting rid of redundant setsockopt calls (ie, a call to
> establish the value that we already know is in force) would help more.

I originally did this but went in favor of simpler code. Are the extra
syscalls an issue? I didn't think they were that expensive..

> Alternatively, we could lose the frammish that PostgreSQL can tell you
> what the system defaults are: 0 in the GUC just means "do nothing",
> not "find out what the current setting is on the off chance that the
> user might want to know".

I didn't do this as it meant that using SET tcp_whatever = 0 does *not*
reset the setting to what you'd get with a value of 0 in
postgresql.conf, which seemed confusing to me.

This could all get simpler if we didn't allow per-connection changing of
that GUC (i.e. set it once at startup and forget about it), which
probably isn't unreasonable. I wonder if those socket options get
inherited from the listening socket? Will check.

-O

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2005-05-26 23:26:59 A 2 phase commit weirdness
Previous Message Tom Lane 2005-05-26 22:16:55 Re: WAL replay failure after file truncation(?)

Browse pgsql-patches by date

  From Date Subject
Next Message Jacques I. Peterson, V 2005-05-27 00:54:47 Breaking News
Previous Message Peter Eisentraut 2005-05-26 22:30:39 Re: pgsql: Add PL/pgSQL SQLSTATE and SQLERRM support which sets these values