David G Johnston <david.g.johnston@gmail.com> wrote:
> Vik Fearing [via PostgreSQL] <[hidden email]>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? 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?
That's what Vik did in his patch, and what I was questioning. I
think he might be right, but I want to think about it.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
