Re: [Reveiw] Idle In Transaction Session Timeout, revived

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

In response to

Browse pgsql-hackers by date

  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