Re: idle_in_transaction_timeout
От | David G Johnston |
---|---|
Тема | Re: idle_in_transaction_timeout |
Дата | |
Msg-id | CAKFQuwZCg2uur=tUdz_C2aUwBo87ofFGhn9Mx_HZ4QD-b8fe2Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: idle_in_transaction_timeout (Abhijit Menon-Sen <ams@2ndQuadrant.com>) |
Список | pgsql-hackers |
At 2014-06-19 17:53:17 +0200, [hidden email] wrote:If you look at similar settings like statement_timeout, lock_timeout,
>
> I much prefer with "in" but it doesn't much matter.
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.
David J.
View this message in context: Re: idle_in_transaction_timeout
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
В списке pgsql-hackers по дате отправления: