Re: idle_in_transaction_timeout

On 06/24/2014 03:29 PM, David G Johnston wrote:
> On Tue, Jun 24, 2014 at 9:20 AM, Vik Fearing [via PostgreSQL] <[hidden
> email] </user/SendEmail.jtp?type=node&node=5808883&i=0>>wrote:
> 
>     On 06/22/2014 05:11 PM, Kevin Grittner wrote:
>     > I found one substantive issue that had been missed in discussion,
>     > though.  The patch modifies the postgres_fdw extension to make it
>     > automatically exempt from an attempt to set a limit like this on
>     > the server to which it connects.  I'm not sure that's a good idea.
>     > Why should this type of connection be allowed to sit indefinitely
>     > with an idle open transaction?  I'm inclined to omit this part of
>     > the patch
> 
>     My reasoning for doing it the way I did is that if a transaction
>     touches
>     a foreign table and then goes bumbling along with other things the
>     transaction is active but the connection to the remote server remains
>     idle in transaction.  If it hits the timeout, when the local
>     transaction
>     goes to commit it errors out and you lose all your work.
> 
>     If the local transaction is actually idle in transaction and the local
>     server doesn't have a timeout, we're no worse off than before this
>     patch. 
> 
> 
> ​Going off of this reading alone wouldn't we have to allow the client to
> set the timeout on the fdw_server - to zero - to ensure reasonable
> operation?

That's what the patch currently does.

> If the client has a process that requires ​10 minutes to
> complete, and the foreign server has a default 5 minute timeout, if the
> client does not disable the timeout on the server wouldn't the foreign
> server always cause the process to abort?

Yes.
-- 
Vik