Re: idle_in_transaction_timeout - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: idle_in_transaction_timeout
Date
Msg-id 20140618215246.GA3806@momjian.us
Whole thread Raw
In response to Re: idle_in_transaction_timeout  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Wed, Jun 18, 2014 at 04:41:30PM -0400, Robert Haas wrote:
> 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.

"Kill connections that are idle in non-empty transaction block for too
long"

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + Everyone has their own god. +



pgsql-hackers by date:

Previous
From: Kevin Grittner
Date:
Subject: Re: delta relations in AFTER triggers
Next
From: Kevin Grittner
Date:
Subject: Re: delta relations in AFTER triggers