| 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: | Whole Thread | Raw Message | 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 |