Re: Feature freeze date for 8.1

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