Re: Built-in connection pooling

On Sun, Jan 28, 2018 at 02:01:07PM -0800, Ivan Novick wrote:
> On Sat, Jan 27, 2018 at 4:40 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>
> On Mon, Jan 22, 2018 at 06:51:08PM +0100, Tomas Vondra wrote:
> Right now, if you hit max_connections, we start rejecting new
> connections.  Would it make sense to allow an option to exit idle
> connections when this happens so new users can connect?
>
>
>
> A lot of users have bash scripts to check the system periodically and canel
> idle connections to prevent other users from getting rejected by max
> connections.  They do this on a timer, like if the session appears to be idle
> more than 10 minutes.
>  
>
> I know we have relied on external connection poolers to solve all the
> high connection problems but it seems there might be simple things we
> can do to improve matters.  FYI, I did write a blog entry comparing
> external and internal connection poolers:
>
>
> Yes, that would be great.
>
> The simplest thing sounds like a GUC that will automitcally end a connection
> idle for X seconds.

Uh, we already have idle_in_transaction_session_timeout so we would just
need a simpler version.

> Another option could be as you suggested, Bruce, if a user would have failed
> because of max connections already reached, then terminate the connection that
> has been idle the longest and allow a new connection to come in.
>
> These would greatly improve user experience as most folks have to automate this
> all themselves anyway.

Plus the ability to auto-free resources like cached system tables if the
backend is idle for a specified duration.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +