Re: idle_in_transaction_timeout

On Tue, Jun 3, 2014 at 7:40 PM, Josh Berkus [via PostgreSQL] <
ml-node+s1045698n5805933h47(at)n5(dot)nabble(dot)com> wrote:

> On 06/03/2014 02:53 PM, Tom Lane wrote:
>
> > Josh Berkus <[hidden email]
> <http://user/SendEmail.jtp?type=node&node=5805933&i=0>> writes:
> >> Out of curiosity, how much harder would it have been just to abort the
> >> transaction? I think breaking the connection is probably the right
> >> behavior, but before folks start arguing it out, I wanted to know if
> >> aborting the transaction is even a reasonable thing to do.
> >
> > FWIW, I think aborting the transaction is probably better, especially
> > if the patch is designed to do nothing to already-aborted transactions.
> > If the client is still there, it will see the abort as a failure in its
> > next query, which is less likely to confuse it completely than a
> > connection loss. (I think, anyway.)
>
> Personally, I think we'll get about equal amounts of confusion either way.
>
> > The argument that we might want to close the connection to free up
> > connection slots doesn't seem to me to hold water as long as we allow
> > a client that *isn't* inside a transaction to sit on an idle connection
> > forever. Perhaps there is room for a second timeout that limits how
> > long you can sit idle independently of being in a transaction, but that
> > isn't this patch.
>
> Like I said, I'm marginally in favor of terminating the connection, but
> I'd be completely satisfied with a timeout which aborted the transaction
> instead. Assuming that change doesn't derail this patch and keep it
> from getting into 9.5, of course.

​Default to dropping the connection but give the usersadministrators the
capability to decide for themselves?

I still haven't heard an argument for why this wouldn't apply to aborted
idle-in-transactions. I get the focus in on releasing locks but if the
transaction fails but still hangs around forever it is just as broken as
one that doesn't fail and hangs around forever. Even if you limit the end
result to only aborting the transaction the end-user will likely want to
distinguish between their transaction failing and their failed transaction
remaining idle too long - if only to avoid the situation where they make
the transaction no longer fail but still hit the timeout.

Whether a connection is a resource the DBA wants to restore (at the expense
of better server-client communication) is a parental decision we shouldn't
force on them given how direct (feelings about GUCs aside). The decision
to force the release of locks - the primary purpose of the patch - is made
by simply using the setting in the first place.

David J.
​

--
View this message in context: http://postgresql.1045698.n5.nabble.com/idle-in-transaction-timeout-tp5805859p5805936.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.