TCP keepalive support for libpq
in [PgSql]
|
From: Robert Haas on 22 Jun 2010 13:32 On Tue, Jun 22, 2010 at 1:14 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: >> On Tue, Jun 22, 2010 at 12:50 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: >>> Robert Haas <robertmhaas(a)gmail.com> writes: >>> By that argument, we need to be programming to bare metal on every disk >>> access. �Does anyone want to argue that depending on vendor-specific >>> filesystem functionality is not a house of cards? �(And unfortunately, >>> that's much too close to the truth ... but yet we're not going there.) > >> I think you're making my argument for me. �The file system API is far >> more portable than the behavior we're proposing to depend on here, and >> yet it's only arguably good enough to meet our needs. > > Uh, it's not API that's at issue here, and as for "not portable" I think > you have failed to make that case. It is true that there are some old > platforms where keepalive isn't adjustable, but I doubt that anything > anyone is likely to be running mission-critical PG 9.0 on will lack it. I don't think the burden of proof is on me to demonstrate that there's a case where this feature isn't available - we're usually quite reluctant to take advantage of platform-specific features unless we have strong evidence that they are fully portable across our entire set of supported platforms. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 22 Jun 2010 13:08 On Tue, Jun 22, 2010 at 12:50 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: >> 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? > > By that argument, we need to be programming to bare metal on every disk > access. �Does anyone want to argue that depending on vendor-specific > filesystem functionality is not a house of cards? �(And unfortunately, > that's much too close to the truth ... but yet we're not going there.) I think you're making my argument for me. The file system API is far more portable than the behavior we're proposing to depend on here, and yet it's only arguably good enough to meet our needs. > As for the original point: *of course* we are going to have to expose > the keepalive parameters. �The default timeouts are specified by RFC, > and they're of the order of hours. �That's not going to satisfy anyone > for this usage. So I see. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Florian Pflug on 22 Jun 2010 13:30 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 23 Jun 2010 21:14 On Tue, Jun 22, 2010 at 12:32 PM, Magnus Hagander <magnus(a)hagander.net> wrote: > I looked around quickly earlier when we chatted about this, and I > think I found an API call to change them for a socket as well - but a > Windows specific one, not the ones you'd find on Unix... Magnus - or anyone who knows Windows - Now that I've committed this patch, any chance you want to add a few lines of code to make this work on Windows also? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Magnus Hagander on 24 Jun 2010 07:04 On Thu, Jun 24, 2010 at 03:14, Robert Haas <robertmhaas(a)gmail.com> wrote: > On Tue, Jun 22, 2010 at 12:32 PM, Magnus Hagander <magnus(a)hagander.net> wrote: >> I looked around quickly earlier when we chatted about this, and I >> think I found an API call to change them for a socket as well - but a >> Windows specific one, not the ones you'd find on Unix... > > Magnus - or anyone who knows Windows - > > Now that I've committed this patch, any chance you want to add a few > lines of code to make this work on Windows also? I can probably look at that, yes. But definitely not until next week, and I can't promise I'll make it next week either. So if somebody else knows what to do, please go ahead and do so - I can definitely commit to *reviewing* it next week :-) -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 Prev: what exactly is a PlaceHolderVar? Next: [HACKERS] Parallel pg_restore versus old dump files |