Hi,

> > This sounds too simple, is it a practical way forward?
>
> It's a high level view only. I borrowed the idea from MsSql.
>
>
> > It sounds as if it could give 'performance time' information
> > such as
> >
> > select rdb$start_time, rdb$request from rdb$requests where
> > rdb$start_time > 'NOW' - (2mins)
>
> Yes, because this information IS in the internal data
> structures, only that
> nobody can see it without a debugger.
>
>
> > I presume that the missing bit is getting the 'delete' to
> > actually cancel the query?
>
> That's the nice thing. :-)
> A couple of semaphores, protecting some data structures, signaling the
> request and ALL its child requests as stopped so they obey
> and notifying the
> sorting phase (ouchhh) because with some monstrous query,
> sorting could be
> taking 40 minutes and you'll want to interrupt it.
> After all, why are we trying to interrupt a query? When it's already
> prepared, it only remains to sort it if needed. Otherwise,
> you stop the
> execution phase by simply not retrieving more rows and unpreparing the
> statement. IB/FB doesn't push records to the client side.
>
> I have a different view than the approach that BORL took and
> found that Toni
> Martir (IBAccess) and other few people have similar ideas.
>
> A user can cancel its queries.
> Sysdba of course can kill any query.
> Not restricted to that, we could bind special roles to
> quotas. IE some users
> can't execute a request for more than 10 minutes or the request is
> terminated automatically... but I'm dreaming.
> Using a SQL interface to manage those issues has advantages and
> disadvantages. Other people will prefer to expand the
> Services API to get
> and modify the same information.

Oracle works the same -- only user SYSTEM and INTERNAL can kill
sessions (not queries, but its almost the same). I very much
prefer using a SQL interface for these kind of things. I also
think there should be more 'system' views for these kind of
things.

What about a views with:

- connected users
- queries (states: preparing, busy (ordering etc), fetching, suspended)
- processes (users, threads, sweep, backup, etc?)

Deleting from connected users would really disconnect,
SYSDBA and DB owner only? How hard would it be for a non-C
programmer (me) to get these kind of things started? How
hard would it be to create these kind of views, Claudio??

And is it possible to create users via SQL statements (SYSDBA
only?) instead of the (juk) services API? How hard would this
be?

Martijn Tonies
InterBase Workbench - the developer tool for InterBase and Firebird
http://www.interbaseworkbench.com


[Non-text portions of this message have been removed]