Re: TCP keepalive support for libpq
От | Robert Haas |
---|---|
Тема | Re: TCP keepalive support for libpq |
Дата | |
Msg-id | AANLkTikOCabJpGjhEzZQ1KyfTwjHydznE_KVEHaeHU_V@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: TCP keepalive support for libpq (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: TCP keepalive support for libpq
Re: TCP keepalive support for libpq |
Список | pgsql-hackers |
On Tue, Jun 22, 2010 at 1:14 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas@gmail.com> writes: >> On Tue, Jun 22, 2010 at 12:50 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> Robert Haas <robertmhaas@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
В списке pgsql-hackers по дате отправления: