Details
-
Type:
Bug
-
Status: Closed
-
Priority:
Minor
-
Resolution: Fixed
-
Affects Version/s: 10.0.2
-
Fix Version/s: 10.0.4
-
Component/s: None
-
Labels:None
Description
Again, I'm not quite sure it's supposed to work, but it seems reasonable: if the server can discover a table on appearance of ARZ file and rediscover it on modification of ARZ file, then why not to anti-discover it when the ARZ file is gone? If it's by design, please close.
The test below is only one line different from a fragment in archive.discover test.
In archive.discover, the select under ER_NO_SUCH_TABLE is done from t1 (which truly doesn't exist), not from t0. I don't know if it was intentional or not.
--source include/have_archive.inc let $mysqld_datadir= `select @@datadir`; create table t0 (i int) engine=archive; select * from t0; remove_file $mysqld_datadir/test/t0.ARZ; flush tables; --error ER_NO_SUCH_TABLE select * from t0; drop table t0; --list_files $mysqld_datadir/test
This test fails with
mysqltest: At line 9: query 'select * from t0' failed with wrong errno 1017: 'Can't find file: './test/t0.ARZ' (errno: 2 "No such file or directory")', instead of 1146...
ER_NO_SUCH_TABLE would have been much more elegant.
revision-id: bar@mnogosearch.org-20130428061831-jqdbd80f4qr62j2e revno: 3747 branch-nick: 10.0
Gliffy Diagrams
Attachments
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
pushed in 10.0-base