On 02/03/2016 02:52 PM, Robert Haas wrote:
On Wed, Feb 3, 2016 at 5:36 PM, Jim Nasby <jim.na...@bluetreble.com> wrote:
I think killing the session is a perfectly sensible thing to do in this
case. Everything meaningful that was done in the session will be rolled
back - no need to waste resources keeping the connection open.
Except you end up losing stuff like every GUC you've set, existing temp
tables, etc. For an application that presumably doesn't matter, but for a
user connection it would be a PITA.
I wouldn't put a bunch of effort into it though. Dropping the connection is
certainly better than nothing.
Well, my view is that if somebody wants an alternative behavior
besides dropping the connection, they can write a patch to provide
that as an additional option. That, too, has been discussed before.
But the fact that somebody might want that doesn't make this a bad or
useless behavior. Indeed, I'd venture that more people would want
this than would want that.
Something feels wrong about just dropping the connection. I can see
doing what connection poolers do (DISCARD ALL) + a rollback but the idea
that we are going to destroy a connection to the database due to an idle
transaction seems like a potential foot gun. Unfortunately, outside of a
feeling I can not provide a good example.
Sincerely,
JD
--
Command Prompt, Inc. http://the.postgres.company/
+1-503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Everyone appreciates your honesty, until you are honest with them.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
