From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | Merlin Moncure <mmoncure(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions |
Date: | 2015-11-03 02:42:35 |
Message-ID: | CAA4eK1+Pw5xg-DhSgHLyd7jpVcKoV2q7PYRuG7aUD5bZw3c=bg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Nov 2, 2015 at 10:45 PM, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
wrote:
>
>
> It is 100% true. But the users can do strange things. If we solve idle
> transactions and not idle session, then they are able to increase
> max_connections to thousands with happy smile in face.
>
> I have not strong idea about how to solve it well - maybe introduce
> transaction_idle_timeout and session_idle_timeout?
>
>
What exactly do we want to define session_idle_timeout? Some
possibilities:
a. Reset the session related variables like transaction, prepared
statements, etc. and retain it for connection pool kind of stuff
b. Exit from the session
If we want something on lines of option (a), then I think it is better
to have just a single time out (session_idle_timeout/idle_timeout)
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-11-03 02:43:07 | Re: Building from git source on ubuntu with gssapi |
Previous Message | Robbie Harwood | 2015-11-03 02:38:05 | Re: Building from git source on ubuntu with gssapi |