On Tue, Jun 22, 2010 at 12:50 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@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