On Tue, Jun 24, 2014 at 9:20 AM, 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?
