mirror of
https://github.com/MariaDB/server.git
synced 2025-12-24 11:21:21 +03:00
f07e4850d0
This saves one byte per Query_log_event on disk compared to 5.0.[0..3]. Compatibility problems with 5.0.x where x<4 are explained in the comments in log_event.cc. Putting back s/my_open(O_TRUNC)/(my_delete+my_create) change which had been wiped away by somebody doing a wrong 4.1->5.0 merge (which happened just before 5.0.3 :( ). Applying it to new events for LOAD DATA INFILE. If slave fails in Execute_load_query_log_event::exec_event(), don't delete the file (so that it's re-usable at next START SLAVE). And (youpi!) fix for BUG#3247 "a partially completed LOAD DATA INFILE is not executed at all on the slave" (storing an Execute_load_query_log_event to binlog, with its error code, instead of Delete_file_log_event). mysql-test/r/mix_innodb_myisam_binlog.result: we now use one less byte when storing the catalog in binlog so positions change mysql-test/r/rpl_change_master.result: we now use one less byte when storing the catalog in binlog so positions change mysql-test/r/rpl_deadlock.result: we now use one less byte when storing the catalog in binlog so positions change mysql-test/r/rpl_error_ignored_table.result: we now use one less byte when storing the catalog in binlog so positions change mysql-test/r/rpl_flush_log_loop.result: we now use one less byte when storing the catalog in binlog so positions change mysql-test/r/rpl_loaddata.result: we now use one less byte when storing the catalog in binlog so positions change. Plus testing replication of LOAD DATA INFILE if duplicate key and non-transactional table. mysql-test/r/rpl_log.result: we now use one less byte when storing the catalog in binlog so positions change mysql-test/r/rpl_max_relay_size.result: we now use one less byte when storing the catalog in binlog so positions change mysql-test/r/rpl_relayrotate.result: we now use one less byte when storing the catalog in binlog so positions change mysql-test/r/rpl_replicate_do.result: we now use one less byte when storing the catalog in binlog so positions change mysql-test/r/rpl_rotate_logs.result: we now use one less byte when storing the catalog in binlog so positions change mysql-test/r/rpl_until.result: we now use one less byte when storing the catalog in binlog so positions change mysql-test/t/mysqlbinlog.test: we now use one less byte when storing the catalog in binlog so positions change mysql-test/t/mysqlbinlog2.test: we now use one less byte when storing the catalog in binlog so positions change mysql-test/t/rpl_deadlock.test: we now use one less byte when storing the catalog in binlog so positions change mysql-test/t/rpl_loaddata.test: we now use one less byte when storing the catalog in binlog so positions change. Plus testing replication of LOAD DATA INFILE if duplicate key and non-transactional table. mysql-test/t/rpl_until.test: we now use one less byte when storing the catalog in binlog so positions change sql/log_event.cc: a) We now store the catalog in Query_log_event in binlog WITHOUT its end zero. This saves one byte per Query_log_event on disk. Compatibility problems with 5.0.x where x<4 are explained in the comments in this file. b) putting back s/my_open(O_TRUNC)/(my_delete+my_create) change which had been wiped away by somebody doing a wrong 4.1->5.0 merge (which happened just before 5.0.3 :( ). Applying it to new events for LOAD DATA INFILE. c) if slave fails in Execute_load_query_log_event::exec_event(), don't delete the file (so that it's re-usable at next START SLAVE). sql/log_event.h: We now store the catalog in Query_log_event in binlog WITHOUT its end zero. This saves one byte per Query_log_event on disk. This new storage for the catalog is denoted by Q_CATALOG_NZ_CODE (couldn't re-use Q_CATALOG_CODE as 5.0.3 slaves of this 5.0.4 master would segfault because it would expect a 0 when there is none. Renaming get_open_mode() to get_create_or_append() (see log_event.cc) sql/sql_load.cc: Fix for BUG#3247: if LOAD DATA INFILE fails but has permanently updated a table (i.e. has deleted/added/modified some rows in a non-transactional table), we must write an Execute_load_query_log_event to binlog (with the error code, as this class beautifully inherits from Query_log_event, it can store the error code - thanks Dmitri) and not a Delete_file_log_event (we use to write a Delete_file_log_event: no update happened on slave, bug).
This directory contains a test suite for 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. If you want to run the test with a running MySQL server use the --external option to mysql-test-run. 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. All tests must pass. If one or more of them fail on your system, please read the following manual section of how to report the problem: http://dev.mysql.com/doc/mysql/en/MySQL_test_suite.html You can create your own test cases. To create a test case: xemacs t/test_case_name.test in the file, put a set of SQL commands that will create some tables, load test data, run some queries to manipulate it. We would appreciate if the test tables were called 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 will ensure that one can run the test over and over again. If you are using mysqltest commands (like result file names) in your test case you should do 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 consistent of SQL commands and comments you can create the test case 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 --record-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 wrong, 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. To submit your test case, 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://support.mysql.com/pub/mysql/secret/ and send a mail to bugs@lists.mysql.com