Vik, > When the timeout occurs, the backend commits suicide with a FATAL > ereport. I thought about just aborting the transaction to free the > locks but decided that the client is clearly broken so might as well > free up the connection as well.
Out of curiosity, how much harder would it have been just to abort the transaction? I think breaking the connection is probably the right behavior, but before folks start arguing it out, I wanted to know if aborting the transaction is even a reasonable thing to do. Argument in favor of breaking the connection: most of the time, IITs are caused by poor error-handling or garbage-collection code on the client side, which has already abandoned the application session but hadn't let go of the database handle. Since the application is never going to reuse the handle, terminating it is the right thing to do. Argument in favor of just aborting the transaction: client connection management software may not be able to deal cleanly with the broken connection and may halt operation completely, especially if the client finds out the connection is gone when they try to start their next transaction on that connection. My $0.019999999999998: terminating the connection is the preferred behavior. > The same behavior can be achieved by an external script that monitors > pg_stat_activity but by having it in core we get much finer tuning (it > is session settable) and also traces of it directly in the PostgreSQL > logs so it can be graphed by things like pgbadger. > > Unfortunately, no notification is sent to the client because there's no > real way to do that right now. Well, if you abort the connection, presumably the client finds out when they try to send a query ... -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
