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
