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. 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. Vladimir
