mariadb/mysql-test
Michael Widenius 424e9a888d Fixed several errors in Aria discovered by test case for lp:727869 ma_pagecache.c:2103: find_block: Assertion `block->rlocks == 0
- Fixed assert in transaction log handler when aria_check was run on block-record table that was much bigger than expected.
- Fixed warnings about wrong mutex order between bitmap and intern_lock
- Fixed error in bitmap that could cause two rows to use same block for a block record.
- Fixed wrong test that could cause error if last page for a bitmap was used by a blob.
- Fixed several bugs in pagecache for the case where pagecase had very few blocks and there was a lot of threads competing to get the blocks (very unlikely case).


mysql-test/suite/maria/r/maria-recovery3.result:
  Updated results
sql/mysqld.cc:
  Allow mi_check() to send information messages for log file
storage/maria/ma_bitmap.c:
  Fixed problem with wrong mutex order when bitmap was the first page that was flushed out of page cache
  - Fixed by introducing _ma_bitmap_mark_file_changed() that marks file changed without a bitmap lock.
  - Fixed one case in _ma_change_bitmap_page() where we didn't mark the bitmap changed. This could cause to rows to reuse same block if this was the only change to the bitmap.
  - Split _ma_bitmap_get_page_bits() in two parts to not take a bitmap lock when we already have it
  - Fixed bug in _ma_bitmap_set_full_page_bits() that caused an error if last page for a bitmap was used by a blob
storage/maria/ma_check.c:
  Better handling of wrong file length.
  Fixed bug when we tried to write to transaction log when it was not opened (happened when block record file was bigger than expected)
storage/maria/ma_pagecache.c:
  Fixed several bugs in pagecache for the case where pagecase had very few blocks and there was a lot of threads competing to get the blocks:
  - In link_block() mark a block given to another thread with PCBLOCK_REASSIGNED to ensure that no other threads can start re-using the block
    before the thread that requsted a block.
  - In free_block(), don't reset status for a block that is in re-assign by link_block() (we don't want to loose the PCBLOCK_REASSIGNED flag).
  - Added call to wait_for_flush() when we got a new block in find_block() to ensure that we don't use a block that is beeing flushed by another thread.
  - Moved setting of hits_left and last_hit_time in find_block() to where we assign the block.
  
  
  Code cleanup and making code uniform:
  - Changed a lot of KEYCACHE_DBUG_PRINT to use DBUG_PRINT
  - Streamlined all reporting of 'signal' and 'wait' between threads to be identical.
  - Use thread name instead of thread number (for each match against --debug)
  - Added more DBUG_ENTER, DBUG_PRINT and DBUG_ASSERT()
  - Added more comments
storage/myisam/ha_myisam.cc:
  Only print information about that we make a backup if we are really making a backup.
storage/myisam/mi_check.c:
  Inform mysqld that we are creating a backup of the data file (for inclusion in error log).
2011-06-24 12:08:45 +03:00
..
collections
extra
include Cherrypick fix for maria recovery bug LPBUG#686006 from 5.2 2011-05-04 16:03:52 +02:00
lib Made test-unit run in parlallel. This was achived by having all aria tests that uses temporary files to create the temporary file in an unique tempdirectory. 2011-05-13 16:22:05 +03:00
r Updated to new error messages for partitions when .par file is missing 2011-06-11 14:53:08 +03:00
std_data
suite Fixed several errors in Aria discovered by test case for lp:727869 ma_pagecache.c:2103: find_block: Assertion `block->rlocks == 0 2011-06-24 12:08:45 +03:00
t Fixed portability problem with partiton_error.test 2011-06-13 12:46:11 +03:00
CMakeLists.txt
Makefile.am
mtr.out-of-source
mysql-stress-test.pl
mysql-test-run.pl Fixed portability problem with partiton_error.test 2011-06-13 12:46:11 +03:00
purify.supp
README
README.gcov
README.stress
README.suites
valgrind.supp

This directory contains a test suite for the MySQL daemon. To run
the currently existing test cases, simply execute ./mysql-test-run in
this directory. It will fire up the newly built mysqld and test it.

Note that you do not have to have to do "make install", and you could
actually have a co-existing MySQL installation. The tests will not
conflict with it. To run the test suite in a source directory, you
must do make first.

All tests must pass. If one or more of them fail on your system, please
read the following manual section for instructions on how to report the
problem:

http://kb.askmonty.org/v/reporting-bugs

If you want to use an already running MySQL server for specific tests,
use the --extern option to mysql-test-run. Please note that in this mode,
the test suite expects you to provide the names of the tests to run.
For example, here is the command to run the "alias" and "analyze" tests
with an external server:

mysql-test-run --extern socket=/tmp/mysql.sock alias analyze

To match your setup, you might also need to provide --socket, --user, and
other relevant options.

With no test cases named on the command line, mysql-test-run falls back
to the normal "non-extern" behavior. The reason for this is that some
tests cannot run with an external server.

You can create your own test cases. To create a test case, create a new
file in the t subdirectory using a text editor. The file should have a .test
extension. For example:

 xemacs t/test_case_name.test

 In the file, put a set of SQL statements that create some tables,
 load test data, and run some queries to manipulate it.

 We would appreciate it if you name your test tables t1, t2, t3 ... (to not
 conflict too much with existing tables).

 Your test should begin by dropping the tables you are going to create and
 end by dropping them again.  This ensures that you can run the test over
 and over again.
 
 If you are using mysqltest commands (like result file names) in your
 test case, you should create the result file as follows:

 mysql-test-run --record test_case_name

 or

 mysqltest --record < t/test_case_name.test

 If you only have a simple test cases consisting of SQL statements and
 comments, you can create the test case in one of the following ways:

 mysql-test-run --record test_case_name

 mysql test < t/test_case_name.test > r/test_case_name.result

 mysqltest --record --database test --result-file=r/test_case_name.result < t/test_case_name.test

 When this is done, take a look at r/test_case_name.result
 - If the result is incorrect, you have found a bug. In this case, you should
   edit the test result to the correct results so that we can verify
   that the bug is corrected in future releases.

If you want to submit your test case you can send it 
to maria-developers@lists.launchpad.com or attach it to a bug report on
https://bugs.launchpad.net/maria/.

If the test case is really big or if it contains 'not public' data,
then put your .test file and .result file(s) into a tar.gz archive,
add a README that explains the problem, ftp the archive to
ftp://ftp.askmonty.org/private and send a mail to
https://bugs.launchpad.net/maria/ about it.