On 2014-06-24 10:04:03 -0400, Robert Haas wrote: > On Tue, Jun 24, 2014 at 9:18 AM, Vik Fearing <vik.fear...@dalibo.com> wrote: > > 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. > > I think we are. First, the correct timeout is a matter of > remote-server-policy, not local-server-policy. If the remote server > wants to boot people with long-running idle transactions, it's > entitled to do that, and postgres_fdw shouldn't assume that it's > "special". The local server policy may be different, and may not even > have been configured by the same person. Second, setting another GUC > at every session start adds overhead for all users of postgres_fdw.
+1 > Now, it might be that postgres_fdw should have a facility to allow > arbitrary options to be set on the foreign side at each connection > startup. Then that could be used here if someone wants this behavior. > But I don't think we should hard-code it, because it could also be NOT > what someone wants. I think options=-c idle_in_transaction_timeout=0 in the server config should already do the trick. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers