Re: idle_in_transaction_timeout - Mailing list pgsql-hackers
| From | David G Johnston |
|---|---|
| Subject | Re: idle_in_transaction_timeout |
| Date | |
| Msg-id | CAKFQuwYwHkZXwt-NaUXsEP3XuSAunzbgPo8cbe_2Nv6M89hN1g@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
(Vik Fearing <vik.fearing@dalibo.com>)
|
| List | pgsql-hackers |
On 06/03/2014 02:53 PM, Tom Lane wrote:Personally, I think we'll get about equal amounts of confusion either way.
> Josh Berkus <[hidden email]> 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.)Like I said, I'm marginally in favor of terminating the connection, but
> 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.
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: Re: idle_in_transaction_timeout
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
pgsql-hackers by date: