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

From Bruce Momjian
Subject Re: Built-in connection pooling
Date
Msg-id 20180129153402.GB11613@momjian.us
Whole thread Raw
In response to Re: Built-in connection pooling  (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>)
Responses Re: Built-in connection pooling
List pgsql-hackers
On Mon, Jan 29, 2018 at 11:57:36AM +0300, Konstantin Knizhnik 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?
> 
> It will require changes in client applications, will not it? Them should be
> ready that connection can be dropped by server at any moment of time.
> I do not know it is possible to drop idle connection and hide this fact from
> the client. In my implementation each session keeps minimal necessary
> information requires for interaction with client (session context).  It
> includes socket, struct Port and session memory context which should be used
> instead of TopMemoryContext for session specific data.

Yes, it would impact applications and you are right most applications
could not handle that cleanly.  It is probably better to look into
freeing resources for idle connections instead and keep the socket open.

-- 
  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: Simon Riggs
Date:
Subject: Re: [HACKERS] MERGE SQL Statement for PG11
Next
From: Tom Lane
Date:
Subject: Re: A Generic Question about Generic type subscripting