> -----Original Message-----
> From: Firebird-Architect@yahoogroups.com
> [mailto:Firebird-Architect@yahoogroups.com] On Behalf Of Nando Dessena
> Sent: 13. juni 2005 20:20
> To: Firebird-Architect@yahoogroups.com
> Subject: Re: [Firebird-Architect] Can we, can we, can we????...
>
> Jim,
>
> J> Is a timeout elapsed time or cpu time?
>
> good question. OTTOMH I'd say whichever comes first.

Neither I think.

>
> 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
> J> restart 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.

That seems to make a lot of sence.

> J> CPU might be better, but it appears that pthreads doesn't
> provide any
> J> mechanism to get per thread CPU numbers, so I'm afraid
> we're going to
> J> 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
> J> a limit would be computationally cheap. Numbers ecords read is
> J> another possibility, but it would have to be records
> fetched rather
> J> than records 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?
>

Number of record reads seems like the way to go to me, if a sort of
"timeout" should be implemented.

I though have difficult to see why we need such server functionality (that
might become a problem in itself) to protect against badly written client
applications and/or database designs.

/smn