Tom Lane wrote:
> We would? Why? Please provide a motivation that justifies the
> considerably higher cost to make it count that way, as opposed to
> time-since-BEGIN.
The specific scenario this feature is intended to resolve is
idle-in-transaction backends holding on to resources while the network
connection times out; it isn't intended to implement "I never want to
run a transaction that takes more than X seconds to execute." While
long-running transactions aren't usually a great idea, I can certainly
imagine installations in which some transactions might take, say, 30
minutes to execute but the admin would like to timeout idle connections
in less than that amount of time.
As for cost, this feature has zero cost until it is enabled. I would
also guess that setitimer() is reasonably cheap on most kernels,
although let me know if I'm mistaken. If it's sufficiently expensive
that a setitimer() per query is noticeable, then I agree that
setitimer() at BEGIN-time is probably sufficient for most people.
> Once we've been motivated to try to send an error message to the
> client, the relevant timeouts are way shorter than they are under
> connection-idle conditions.
Sorry, yes, I should have been more clear.
-Neil
