Re: Implement support for TCP_KEEPCNT, TCP_KEEPIDLE, TCP_KEEPINTVL

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Oliver Jowett <oliver(at)opencloud(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-patches(at)postgresql(dot)org
Subject: Re: Implement support for TCP_KEEPCNT, TCP_KEEPIDLE, TCP_KEEPINTVL
Date: 2005-06-04 15:49:11
Message-ID: 200506041549.j54FnBN20120@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches


Is this patch being worked on?

---------------------------------------------------------------------------

Oliver Jowett wrote:
> 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
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2005-06-04 15:55:37 Re: Precedence of %
Previous Message Tom Lane 2005-06-04 15:46:07 Re: Quick-and-dirty compression for WAL backup blocks

Browse pgsql-patches by date

  From Date Subject
Next Message Magnus Hagander 2005-06-04 16:29:05 Re: Simplify Win32 Signaling code
Previous Message Bruce Momjian 2005-06-04 14:09:58 Re: [GENERAL] numeric precision when raising one numeric to another.