Hello Ingo,
Ingo Strüwing a écrit, Le 08.04.2009 09:30:
> Hi Guilhem,
>
> thanks for the review.
>
> Guilhem Bichot, 07.04.2009 21:32:
>
> ...
>> Ingo Struewing a écrit, Le 07.04.2009 21:05:
> ...
>>> 2810 Ingo Struewing 2009-04-07
>>> Bug#44068 - RESTORE can disable the MyISAM Key Cache
>>> The test case myisam_keycache_coverage used to fail if it ran
>>> after backup_myisam_sync.
>>> === modified file 'mysql-test/t/myisam_keycache_coverage.test'
>>> +SET debug='-d,key_cache_write_block_error';
>>> FLUSH TABLE t1;
>>>
>>> --echo #
>>> --echo # Cleanup
>>> --echo #
>>> -SET debug='';
>>> DROP TABLE t1;
>> Ok, as long as mtr does not report "check-testcase" errors regarding DEBUG.
>
>
> It doesn't. That's because I undo every change. Every +d,something
> follows a -d,something. The DBUG trace shows that it works as expected.
> I did temporarily added SELECT @@debug and verified that the variable
> value is the same at begin and end of the test case.
And check-testcase sees no problem when running the test with --debug I
guess.
> Every +d,something turns off DBUG_PRINT output in the default case,
> where no DBUG keyword is explicitly requested. The next -d,something
> re-activates the DBUG_PRINT output again. So it seems to be the least
> disturbing way to use error injection via DBUG.
>
> But still it turns of debugging for the probably most interesting
> statement.
Try this:
SET debug='+d:+d,key_cache_write_block_error';
your_test_statements;
SET debug='+d:-d,key_cache_write_block_error';
From what I tested it should leave debugging on while
your_test_statements run.
> I wish we wouldn't need to abuse the DBUG facility for error
> injection. I think it would be better to have a ERROR_INJECT variable
> for this purpose. Like the DEBUG_SYNC facility it might be configurable
> independent of DBUG, so that error injection test cases could also be
> tested with an (almost) production server.
I have no strong opinion on this. I'm fine if DBUG is considered
"everything you
need to do weird things in testing" (error injection etc).
>>> === modified file 'storage/myisam/myisamlog.c'
>>> --- a/storage/myisam/myisamlog.c 2009-02-22 18:02:16 +0000
>>> +++ b/storage/myisam/myisamlog.c 2009-04-07 19:05:08 +0000
>>> @@ -80,9 +80,19 @@ int main(int argc, char **argv)
>>> printf("Trying to %s MyISAM files according to log '%s'\n",
>>> (mi_exl.recover ? "recover" : "update"),mi_exl.log_filename);
>>>
>>> + /*
>>> + mi_examine_log() may work faster with an initialized key cache.
>>> + But it works also if the initialization fails.
>> Ok, didn't know that.
>
> I guess, you refer to "But it works also if the initialization fails".
> In this case key_cache_read()/_write() bypass the cache and read/write
> directly to the index file. There is no synchronization problem as a
> writer has exclusive access through thr_lock and/or my_lock. Flushes,
> which are done outside of thr_lock, are no-ops, if the cache is not
> initialized.
>
> This all may not be true with the Maria page cache though. But I'm not sure.
Right, I'm finding out that it's not true for Maria.
Ok to push.
