| From: | Bruce Momjian <bruce(at)momjian(dot)us> |
|---|---|
| To: | Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru> |
| Cc: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Claudio Freire <klaussfreire(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Built-in connection pooling |
| Date: | 2018-01-29 15:34:02 |
| Message-ID: | 20180129153402.GB11613@momjian.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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(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 +
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2018-01-29 15:42:29 | Re: A Generic Question about Generic type subscripting |
| Previous Message | Simon Riggs | 2018-01-29 15:32:52 | Re: [HACKERS] MERGE SQL Statement for PG11 |