Re: idle_in_transaction_timeout - Mailing list pgsql-hackers

From Robert Haas
Subject Re: idle_in_transaction_timeout
Date
Msg-id CA+TgmobD1+Sa1H2jM8FwiNzSM7NL-UyMC0+mSG=0OwSWkc3P2Q@mail.gmail.com
Whole thread Raw
In response to Re: idle_in_transaction_timeout  (Josh Berkus <josh@agliodbs.com>)
Responses Re: idle_in_transaction_timeout  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On Wed, Jun 18, 2014 at 3:53 PM, Josh Berkus <josh@agliodbs.com> wrote:
> On 06/18/2014 12:32 PM, Tom Lane wrote:
>> Josh Berkus <josh@agliodbs.com> writes:
>>>  There are plenty of badly-written applications which "auto-begin", that
>>> is, they issue a "BEGIN;" immediately after every "COMMIT;" whether or
>>> not there's any additional work to do.  This is a major source of IIT
>>> and the timeout should not ignore it.
>>
>> Nonsense.  We explicitly don't do anything useful until the first actual
>> command arrives, precisely to avoid that problem.
>
> Oh, we don't allocate a snapshot?  If not, then no objection here.

The only problem I see is that it makes the semantics kind of weird
and confusing.  "Kill connections that are idle in transaction for too
long" is a pretty clear spec; "kill connections that are idle in
transaction except if they haven't executed any commands yet because
we think you don't care about that case" is not quite as clear, and
not really what the GUC name says, and maybe not what everybody wants,
and maybe masterminding.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [COMMITTERS] pgsql: Reduce the number of semaphores used under --disable-spinlocks.
Next
From: Robert Haas
Date:
Subject: Re: Atomics hardware support table & supported architectures