Details
-
Bug
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Fixed
-
10.0.2
-
None
-
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
|