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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
