On 2014-06-24 10:04:03 -0400, Robert Haas wrote:
> On Tue, Jun 24, 2014 at 9:18 AM, Vik Fearing <vik.fearing@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
