From: | Stéphane Schildknecht <stephane(dot)schildknecht(at)postgres(dot)fr> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [Reveiw] Idle In Transaction Session Timeout, revived |
Date: | 2016-02-06 08:44:41 |
Message-ID: | 56B5B279.2070200@postgres.fr |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 31/01/2016 14:33, Vik Fearing wrote:
> Attached is a rebased and revised version of my
> idle_in_transaction_session_timeout patch from last year.
>
> This version does not suffer the problems the old one did where it would
> jump out of SSL code thanks to Andres' patch in commit
> 4f85fde8eb860f263384fffdca660e16e77c7f76.
>
> The basic idea is if a session remains idle in a transaction for longer
> than the configured time, that connection will be dropped thus releasing
> the connection slot and any locks that may have been held by the broken
> client.
>
> Added to the March commitfest.
>
>
>
>
Hello,
I've looked at this patch, which I'd be able to review as a user, probably not
at a code level.
It seems to me this is a need in a huge number of badly handled idle in
transaction sessions (at application level).
This feature works as I expected it to.
My question would be regarding the value 0 assigned to the GUC parameter to
disable it. Wouldn't be -1 a better value, similar to
log_min_duration_statement or similar GUC parameter?
(I understand you can't put a 0ms timeout duration, but -1 seems more
understandable).
Best regards,
--
Stéphane Schildknecht
Contact régional PostgreSQL pour l'Europe francophone
Loxodata - Conseil, expertise et formations
06.17.11.37.42
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2016-02-06 09:03:14 | Re: Explanation for bug #13908: hash joins are badly broken |
Previous Message | Michael Paquier | 2016-02-06 07:49:51 | Re: First-draft release notes for next week's back-branch releases |