pgbouncer has idle_transaction_timeout defined some years without any
problems, so we can take this design
If client has been in "idle in transaction" state longer, it will be
Default: 0.0 (disabled)
This feature can be very important, and I seen a few databases thas was
unavailable due leaked transaction.
2014-06-19 1:46 GMT+02:00 Josh Berkus <j...@agliodbs.com>:
> On 06/18/2014 02:52 PM, Bruce Momjian wrote:
> > On Wed, Jun 18, 2014 at 04:41:30PM -0400, Robert Haas wrote:
> >> 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"
> Here's the POLS violation in this:
> "I have idle_in_transaction_timeout set to 10min, but according to
> pg_stat_activity I have six connections which are IIT for over an hour.
> What gives?"
> Robert's right, not killing the "BEGIN;" only transactions is liable to
> result in user confusion unless we label those sessions differently in
> pg_stat_activity. Tom is right in that killing them will cause some
> users to not use IIT_timeout when they should, or will set the timeout
> too high to be useful.
> So it seems like what we should do is NOT call sessions IIT if they've
> merely executed a BEGIN; and not done anything else. Then the timeout
> and pg_stat_activity would be consistent.
> Counter-argument: most app frameworks which do an automatic BEGIN; also
> do other stuff like SET TIMEZONE each time as well. Is this really a
> case worth worrying about?
> Josh Berkus
> PostgreSQL Experts Inc.
> Sent via pgsql-hackers mailing list (email@example.com)
> To make changes to your subscription: