Jim,

J> Is a timeout elapsed time or cpu time?

good question. OTTOMH I'd say whichever comes first.

J> Elapsed time is problematic on a
J> heavily loaded system since delay can be induced by other requests
J> either hogging the system or holding a blocking resource. Killing a
J> valid request seems more than a little unfair, but killing a valid
J> request in a heavy loaded system that is going to automatically restart
J> is a guarantee of livelock.

We should consider the reason why people ask for this feature: when
there is a runaway query, in current versions of Firebird practically
nothing else happens. That's why they need to kill it. With more
granularity, the need to kill might well disappear.

J> CPU might be better, but it appears that
J> pthreads doesn't provide any mechanism to get per thread CPU numbers, so
J> I'm afraid we're going to have to write that off.

I'm not experienced with posix pthreads so I cannot comment.

J> How about limiting the number of fetches? We already track that, so a
J> limit would be computationally cheap. Numbers ecords read is another
J> possibility, but it would have to be records fetched rather than records
J> returned. Number of update operations, maybe?

The problem is that some "runaway queries" tend to waste a great deal of
time doing things that don't depend on the number of records returned
or updated, like scanning poorly selective indexes or collecting
garbage... Number of reads sounds good to me, as it would be common to
all 4 DML operations, wouldn't it?

Ciao
--
Nando Dessena
http://www.flamerobin.org