| From: | Vik Fearing <vik(dot)fearing(at)dalibo(dot)com> |
|---|---|
| To: | Kevin Grittner <kgrittn(at)ymail(dot)com>, Abhijit Menon-Sen <ams(at)2ndquadrant(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Josh Berkus <josh(at)agliodbs(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net> |
| Subject: | Re: idle_in_transaction_timeout |
| Date: | 2014-06-24 13:18:34 |
| Message-ID: | 53A97AAA.2010906@dalibo.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
--
Vik
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David G Johnston | 2014-06-24 13:29:21 | Re: idle_in_transaction_timeout |
| Previous Message | David Brownlee | 2014-06-24 12:43:32 | Re: PostgreSQL for VAX on NetBSD/OpenBSD |