Re: idle_in_transaction_timeout - Mailing list pgsql-hackers

From Abhijit Menon-Sen
Subject Re: idle_in_transaction_timeout
Date
Msg-id 20140619164004.GA6702@toroid.org
Whole thread Raw
In response to Re: idle_in_transaction_timeout  (Vik Fearing <vik.fearing@dalibo.com>)
Responses Re: idle_in_transaction_timeout  (David G Johnston <david.g.johnston@gmail.com>)
List pgsql-hackers
At 2014-06-19 17:53:17 +0200, vik.fearing@dalibo.com 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", while
for the ERROR variant it would be "idle_transaction_timeout".

Both those names pass the "What's timing out?" test. But
"idle_in_transaction_timeout" alone doesn't, and that's why I can't
bring myself to like it. And pgbouncer's use of
"idle_transaction_timeout" is a weak precedent to continue to use the
same name for the same functionality.

Anyway, as you say, it doesn't matter so much. I promise I won't beat
the nomenclature horse any more. I just wanted to explain my thinking
once. Sorry for dragging it out.

-- Abhijit



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Re: [REVIEW] Re: Re: BUG #9578: Undocumented behaviour for temp tables created inside query language (SQL) functions
Next
From: Noah Misch
Date:
Subject: Re: Crash on backend exit w/ OpenLDAP [2.4.24, 2.4.31]