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 <br...@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 +