Very complex select statements can create temporary tables
that are too big to be represented as a MyISAM table.

This was not checked at table creation time, but only at
open time. The result was an attempt to delete the 
"impossible" table.

But if the server is built --with-raid, MyISAM tries to 
open the table before deleting the files. It needs to find 
out if the table uses the raid support and how many raid 
chunks there are. This is done with an open "for repair",
which will almost always succeed.

But in this case we have an "impossible" table. The open
failed. Hence the files were not deleted. Also the error
message was a bit unspecific.

I turned an open error in this situation into the assumption 
of having no raid support on the table. Thus the normal data 
file is tried to be deleted. This may however leave existing 
raid chunks behind.

I also added a check in mi_create() to prevent the creation
of an "impossible" table. A more decriptive error message is
given in this case.

No test case. The required select statement is way too
large for the test suite. I added a test script to the
bug report.


myisam/mi_create.c:
  Bug#11824 - internal /tmp/*.{MYD,MYI} files remain, causing subsequent queries to fail
  Added a check to mi_create() that the table description
  header of the index file does not exceed 64KB. The header
  has only 16 bits to encode its length.
myisam/mi_delete_table.c:
  Bug#11824 - internal /tmp/*.{MYD,MYI} files remain, causing subsequent queries to fail
  Interpret error in table open as not having a raid
  configuration on the tbale. Thus try to delete the
  normal data file, but leave behind raid chunks if 
  they exist.