On 06/23/2014 03:52 PM, Andres Freund wrote: > On 2014-06-23 13:19:47 -0700, Kevin Grittner wrote: >>>>> which already seems less clear (because the transaction belongs >>>>> to idle) >> >> I have no idea what that means. > > It's "idle_in_transaction"_session_timeout. Not > "idle_in"_transaction_session_timeout. > >>>>> and for another that distinction seems to be to subtle for users. >> >> The difference between an "idle in transaction session" and an >> "idle transaction" is too subtle for someone preparing to terminate >> one of those? > > Yes. To me that's an academic distinction. As a nonnative speaker it > looks pretty much random that one has an "in" in it and the other > doesn't. Maybe I'm just having a grammar fail, but there doesn't seem to > be much sense in it.
As a native speaker, I find the distinction elusive as well. If someone was actually planning to commit transaction cancel, I'd object to it.
And frankly, it doesn't make any sense to have two independent timeouts anyway. Only one of them would ever be invoked, whichever one came first. If you really want to plan for a feature I doubt anyone is going to write, the appropriate two GUCs are:
idle_transaction_timeout: ## ms idle_transaction_timeout_action: cancel | terminate
However, since I'm not convinced that anyone is ever going to write the "cancel" version, can we please just leave the 2nd GUC out for now?
>>> A long idle in transaction state pretty much always indicates a >>> problematic interaction with postgres. >> >> True. Which makes me wonder whether we shouldn't default this to >> something non-zero -- even if it is 5 or 10 days.
I'd go for even shorter: 48 hours. I'd suggest 24 hours, but that would trip up some users who just need really long pg_dumps.
long transactions should not be a problem - this should to break transaction when it does >>nothing<< long time.
