MySQL Bugs: #5175: can't DROP MERGE table if either file is missing

Bug #5175	can't DROP MERGE table if either file is missing
Submitted:	23 Aug 2004 23:00	Modified:	2 Sep 2004 16:19
Reporter:	Igor Mendelev	Email Updates:
Status:	Can't repeat	Impact on me:	None
Category:	MySQL Server: MyISAM storage engine	Severity:	S2 (Serious)
Version:	4.1.2	OS:	Linux (Linux)
Assigned to:		CPU Architecture:	Any

Description:
if for some reason .MRG and/or .FRM file is missing (im my case due to bug in innobackup) MERGE table can't be dropped - which is clearly nonsense (you should be able to drop any MYISAM or MERGE table no matter how many files it consists of are missing or corrupted).

[team@edge1 perf]$ mysql -u root  perf
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Didn't find any fields in table 'GenericObjectPerf'
Didn't find any fields in table 'GenericObjectSummaryPerf'
Didn't find any fields in table 'InterfacePerf'
Didn't find any fields in table 'InterfaceSummaryPerf'
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 5 to server version: 4.1.2-alpha-20040226-standard

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> drop table GenericObjectPerf;
ERROR 6 (HY000): Error on delete of './perf/GenericObjectPerf.MRG' (Errcode: 2)

How to repeat:
Create merge table, then remove it's .MRG (and/or .FRM) file and try to drop it. 
Have some fun!

Suggested fix:
drop table MUST NOT return with error due to missing or corrupted .MRG or .FRM file!!!

HI!

Thank you so much for writting to us.

We are quite cognizant of the problem that you describe, butI am afraid that it is not that easy to resolve.

Before DROP-ing a table, a server has to check whether anyone is using it, for which it needs access to it's data and if data are not in memory, then files have to be read.

This deficiency will be solvable in 5.0 with a new table cache scheme.

And if MRG file is missing or corrupted, what difference would it make for already running query? Query plan was already constructed - are you saying that MRG file is used after query plan exists? But even if it does, in my case MRG file was missing anyway, so how would it help a running query that some kind of link to it's previous location existed (that prevents me from dropping this merge table  ONLY, NOT tables it consisted of).

Sorry, I wasn't able to repeat it on 4.1.4.
Either your "how to repeat" doesn't include some details that are crucial for the bug, or it was fixed in 4.1.4 already

Indeed it seems that 4.1.4 is OK