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
