Mailing List Archive


Back to the month index Back to the list index
David J. Hughes (bambi@Hughes.com.au)
Wed, 15 Jan 1997 17:38:46 +1000 (EST) 

Date: Wed, 15 Jan 1997 17:38:46 +1000 (EST)
From: "David J. Hughes" <bambi@Hughes.com.au>
Subject: Re: [mSQL] 2.0 - can it cache results?
Message-Id: <Pine.SUN.3.91.970115173127.21123G-100000@webster.AusWeb.com.au>

On Tue, 14 Jan 1997 rasmus@mail1.bellglobal.com wrote:

> Well, if CREATE TABLE returned an error, I don't see this as being a big
> problem. With a pid, a random number and a timestamp, the chances of
> getting duplicates decrease dramatically. And even if you do get a duplicate,
> you just catch the error and generate a new table name and try again. That
> assumes of course that you do a "CREATE TABLE" before the "SELECT INTO".

I don't think you can do that in ANSI terms. The SELECT INTO creates the
table.

> The CERT advisory would certainly not be mSQL related in this case. That is
> like saying that a CERT advisory could be issued about Unix file systems
> because someone writes a script to append hits to a file continuously.

I'd have to disagree. mSQL is available over the net so I could, in
theory, trash any machine on the Net running mSQL 2.0 by sending it bogus
SELECT INTO queries. That is a remote denial of service attack and is
something CERT would be keen to advise people of.

> Personally the way I would use the tables would be to base the name of the
> table on the actual select clause that created it. It then in effect
> becomes a query cache. I will happily manage my query cache myself. I will
> set a limit of say 100 tables and whenever a new one is generated, I delete
> the oldest, or least used, or whatever other logic I decide to use.

Anything like that is riddled with problems. Lets say I write an app
that decides to keep the oldest 20 tmp tables hanging around (the APP is
web based BTW). Suddenly I get 21 people hit the box at the same time
and boom! it's game over because I've blown away a tmp table that was
probably still in use.

How big should the number be? Anything where you set X but if X+1 comes
along you die isn't a good plan.

Providing an effective and user safe scheme is non-trivial but it is
something I have on my list of things to think about.

Sure, the easy (and ANSI) option is to punt the entire problem into the
lap of the user and let them worry about it. If I can find a way to
manage this in the server itself it makes using this feature a lot easier
and much safer. I'm all for making the server as easy to use as
possible. Data management complexity should be in the server rather than
in the clients. It makes writing good client code much easier.

Bambi
...
--------------------------------------------------------------------------
To remove yourself from the Mini SQL mailing list send a message containing
"unsubscribe" to "unsubscribe" to msql-list-request@bunyip.com. Send a message containing
"info msql-list" to majordomo@bunyip.com for info on monthly archives of
the list. For more help, mail owner-msql-list@bunyip.com NOT the msql-list!