Re: idle_in_transaction_timeout

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