On Tue, Jun 24, 2014 at 9:20 AM, Vik Fearing [via PostgreSQL] < ml-node+s1045698n5808882...@n5.nabble.com> 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? David J. -- View this message in context: http://postgresql.1045698.n5.nabble.com/idle-in-transaction-timeout-tp5805859p5808883.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.