Re: idle_in_transaction_timeout

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Josh Berkus <josh(at)agliodbs(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Kevin Grittner <kgrittn(at)ymail(dot)com>, Vik Fearing <vik(dot)fearing(at)dalibo(dot)com>, PG Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: idle_in_transaction_timeout
Date: 2014-06-18 20:41:30
Message-ID: CA+TgmobD1+Sa1H2jM8FwiNzSM7NL-UyMC0+mSG=0OwSWkc3P2Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jun 18, 2014 at 3:53 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> On 06/18/2014 12:32 PM, Tom Lane wrote:
>> Josh Berkus <josh(at)agliodbs(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-06-18 21:04:49 Re: Atomics hardware support table & supported architectures
Previous Message Robert Haas 2014-06-18 20:38:09 Re: [COMMITTERS] pgsql: Reduce the number of semaphores used under --disable-spinlocks.