| From: | "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
|---|---|
| To: | <gsstark(at)mit(dot)edu> |
| Cc: | <tollef(dot)fog(dot)heen(at)collabora(dot)co(dot)uk>,<markokr(at)gmail(dot)com>, <masao(dot)fujii(at)gmail(dot)com>, <robertmhaas(at)gmail(dot)com>, <magnus(at)hagander(dot)net>, <pgsql-hackers(at)postgresql(dot)org>, <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <euler(at)timbira(dot)com> |
| Subject: | Re: TCP keepalive support for libpq |
| Date: | 2010-06-24 12:31:32 |
| Message-ID: | 4C2309D402000025000329B3@gw.wicourts.gov |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Greg Stark wrote:
> we'll find that other timeouts are longer than we expect too. TCP
> Keepalives won't come into it at all if there is any unacked data
> pending -- TCP *will* detect that case but it might take longer
> than you want too and you won't be able to lower it.
If memory servers after twenty years, and the standard hasn't
changed, if you add up all the delays, it can take about nine minutes
maximum for a connection to break due to a wait for unacked data.
That's longer than the values Robert showed (which I think was
between one and two minutes -- can't fine the post at the moment),
but quite a bit less than the two hours and ten minutes you get with
the defaults for keepalive.
-Kevin
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PostgreSQL - Hans-Jürgen Schönig | 2010-06-24 12:35:38 | Re: ECPG FETCH readahead |
| Previous Message | Michael Meskes | 2010-06-24 12:19:22 | Re: ECPG FETCH readahead |