| From: | Florian Pflug <fgp(at)phlo(dot)org> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Euler Taveira de Oliveira <euler(at)timbira(dot)com>, Marko Kreen <markokr(at)gmail(dot)com>, Tollef Fog Heen <tollef(dot)fog(dot)heen(at)collabora(dot)co(dot)uk>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: TCP keepalive support for libpq |
| Date: | 2010-06-22 17:30:55 |
| Message-ID: | 18D6CADB-3706-48DC-BB0B-84B68D71FCE6@phlo.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Jun 22, 2010, at 18:43 , Robert Haas wrote:
> What does bother me is the fact that we are engineering a critical
> aspect of our system reliability around vendor-specific implementation
> details of the TCP stack, and that if any version of any operating
> system that we support (or ever wish to support in the future) fails
> to have a reliable implementation of this feature AND configurable
> knobs that we can tune to suit our needs, then we're screwed. Does
> anyone want to argue that this is NOT a house of cards?
We already depend on TCP keepalives to prevent backends orphaned by client crashes or network outages from lingering around forever. If such a lingering backend is inside a transaction, I'll cause table bloat, prevent clog truncations, and keep tables locked forever.
I'd therefore argue that lingering backends are as least as severe a problem as hung S/R connections are. Since we've trusted keepalives to prevent the former for 10 years now, I think we can risk trusting keepalives to prevent the latter too.
best regards,
Florian Pflug
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2010-06-22 17:32:26 | Re: TCP keepalive support for libpq |
| Previous Message | Alvaro Herrera | 2010-06-22 17:21:09 | Re: missing "else" in postmaster.c? |