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