Re: idle_in_transaction_timeout

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.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com