I raised this a while back on -hackers:
http://archives.postgresql.org/pgsql-hackers/2005-02/msg00397.php
but did not get much feedback.
Perhaps you can interpret silence as consent? :)
Does anyone have comments on that email?
I wouldn't be opposed to it. It would be different than statement_timeout, in that we'd be measuring transaction *idle* time, not total transaction runtime, so perhaps "transaction_idle_timeout" is a better name than "transaction_timeout". Also, presumably when the transaction idle timeout fires, we should just rollback the current transaction, not close the client connection -- so you could potentially have idle backends sticking around for the full TCP timeout period. Since they shouldn't be holding any locks I don't see that as a big problem.
-Neil
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
