On Thu, Jun 19, 2014 at 12:40 PM, Abhijit Menon-Sen-2 [via PostgreSQL] <[hidden email]> wrote:
At 2014-06-19 17:53:17 +0200, [hidden email] wrote: > > I much prefer with "in" but it doesn't much matter.
If you look at similar settings like statement_timeout, lock_timeout, etc., what comes before the _timeout is a concrete *thing* that can timeout, or that a timeout can be applied to (e.g. wal_receiver).
"What's timing out?" "A statement."
But in "idle_in_transaction_timeout", "idle_in_transaction" is not a thing. It's a description of the state of a thing (the thing being a session in the FATAL variant of your patch, or a transaction in the ERROR variant).
"What's timing out?" "An idle in transaction." "Huh?"
Strictly speaking, by this logic, the consistent name for the setting in the FATAL variant would be "idle_in_transaction_session_timeout",
+1; I even suggested something similar (I omitted the "in") - though we hadn't come to a firm conclusion on what behavior we were going to implement at the time. Adding session reasonably precludes us from easily changing our mind later (or giving the user an option) but that doesn't seem likely anyway.
Advocating for the Devil (or a more robust, if probably complicated, solution):
"idle_in_transaction_timeout=10s"
"idle_in_transaction_target=session|transaction"
Would be a valid pair since the first intentionally would not want to specify a target - and thus does not fit within the pattern you defined.
"idle_transaction_timeout" is bad since idle is a valid state that is not being affected by this patch; whereas pgbouncer indeed drops truly idle connections.
