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.
