Re: Built-in connection pooling

On Mon, Jan 29, 2018 at 04:02:22PM +0000, Vladimir Sitnikov wrote:
> Bruce>Yes, it would impact applications and you are right most applications
> could not handle that cleanly.
>
> I would disagree here.
> We are discussing applications that produce "lots of idle" connections, aren't
> we? That typically comes from an application-level connection pool.
> Most of the connection pools have a setting that would "validate" connection in
> case it was not used for a certain period of time.
>
> That plays nicely in case server drops "idle, not in a transaction" connection.

Well, we could have the connection pooler disconnect those, right?

> Of course, there are cases when application just grabs a connection from a pool
> and uses it in a non-transacted way (e.g. does some action once an hour and
> commits immediately). However that kind of application would already face
> firewalls, etc. I mean the application should already be prepared to handle
> "network issues".
>
> Bruce> It is probably better to look into
> Bruce>freeing resources for idle connections instead and keep the socket open.
>
> The application might expect for the session-specific data to be present, so it
> might be even worse if the database deallocates all the things but TCP
> connection.
>
> For instance: application might expect for the server-prepared statements to be
> there. Would you deallocate server-prepared statements for those "idle"
> connections? The app would just break. There's no way (currently) for the
> application to know that the statement expired unexpectedly.

I don't know what we would deallocate yet.

--
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 +