On Sun, Jun 29, 2014 at 12:32 PM, Kevin Grittner <kgrittn@ymail.com> wrote:
>>> Moreover, there would be no way to implement a timeout like that without
>>> adding a gettimeofday() call after every packet receipt, which is overhead
>>> we do not need and cannot afford. I don't think this feature should add
>>> *any* gettimeofday's beyond the ones that are already there.
>>
>> That's an especially good point if we think that this feature will be
>> enabled commonly or by default - but as Fujii Masao says, it might be
>> tricky to avoid. :-(
>
> I think that this patch, as it stands, is a clear win if the
> postgres_fdw part is excluded. Remaining points of disagreement
> seem to be the postgres_fdw, whether a default value measured in
> days might be better than a default of off, and whether it's worth
> the extra work of covering more. The preponderance of opinion
> seems to be in favor of excluding the postgres_fdw changes, with
> Tom being violently opposed to including it. I consider the idea
> of the FDW ignoring the server setting dead. Expanding the
> protected area of code seems like it would be sane to ask whoever
> wants to extend the protection in that direction to propose a
> patch. My sense is that there is more support for a default of a
> small number of days than a default of never, but that seems far
> from settled.
>
> I propose to push this as it stands except for the postgres_fdw
> part. The default is easy enough to change if we reach consensus,
> and expanding the scope can be a new patch in a new CF.
> Objections?
Yeah, I think someone should do some analysis of whether this is
adding gettimeofday() calls, and how many, and what the performance
implications are.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
