Re: Built-in connection pooling - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Built-in connection pooling
Date
Msg-id 20180128230054.GB5022@momjian.us
Whole thread Raw
In response to Re: Built-in connection pooling  (Ivan Novick <inovick@pivotal.io>)
Responses Re: Built-in connection pooling
List pgsql-hackers
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@momjian.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@momjian.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 +


pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Wait for parallel workers to attach
Next
From: Thomas Munro
Date:
Subject: Re: Documentation of pgcrypto AES key sizes