- 24 Jun, 2010 3 commits
-
-
Ramil Kalimullin authored
-
Ramil Kalimullin authored
-
Ramil Kalimullin authored
file .\filesort.cc, line 149 (part II) Problem: the server didn't disregard sort order for some zero length tuples. Fix: skip sort order in such a case (zero length NOT NULL string functions). mysql-test/r/select.result: Fix for bug #54459: Assertion failed: param.sort_length, file .\filesort.cc, line 149 (part II) - test result. mysql-test/t/select.test: Fix for bug #54459: Assertion failed: param.sort_length, file .\filesort.cc, line 149 (part II) - test case. sql/sql_select.cc: Fix for bug #54459: Assertion failed: param.sort_length, file .\filesort.cc, line 149 (part II) - disregard sort order for zero length NOT NULL string functions along with zero length NOT NULL fields.
-
- 22 Jun, 2010 3 commits
-
-
Vasil Dimov authored
-
Alexander Nozdrin authored
-
Magne Mahre authored
mysql-test/suite/perfschema/t/no_threads-master.opt: Innodb will start multiple threads, which is not compatible with --one-thread. Disable innodb to be able to run the test case.
-
- 21 Jun, 2010 6 commits
-
-
Alexander Nozdrin authored
-
Sergey Glukhov authored
-
Sergey Glukhov authored
In process of record search it is not taken into account that inital quick->file->ref value could be inapplicable to range interval. After proper row is found this value is stored into the record buffer and later the record is filtered out at condition evaluation stage. The fix is store a refernce of found row to the handler ref field. mysql-test/r/innodb_mysql.result: test case mysql-test/std_data/intersect-bug50389.tsv: test case mysql-test/t/innodb_mysql.test: test case sql/opt_range.cc: store a refernce of found row to the handler ref field.
-
Joerg Bruehe authored
-
Daniel Fischer authored
-
Alexander Nozdrin authored
-
- 20 Jun, 2010 1 commit
-
-
Magne Mahre authored
InnoDB came in a new version "simultanously" with the commit. This patch is a minor change to the new innodb regression test suite.
-
- 18 Jun, 2010 3 commits
-
-
Ramil Kalimullin authored
mysql_client_binlog_statement Problem: server may read from unassigned memory performing "wrong" BINLOG queries. Fix: never read from unassigned memory. mysql-test/suite/binlog/r/binlog_base64_flag.result: Fix for bug #54393: crash and/or valgrind errors in mysql_client_binlog_statement - test result. mysql-test/suite/binlog/t/binlog_base64_flag.test: Fix for bug #54393: crash and/or valgrind errors in mysql_client_binlog_statement - test case. sql/sql_binlog.cc: Fix for bug #54393: crash and/or valgrind errors in mysql_client_binlog_statement - coded_len should not count trailing '/0'; - never read from unassigned memory.
-
Daniel Fischer authored
-
Joerg Bruehe authored
-
- 17 Jun, 2010 19 commits
-
-
Magne Mahre authored
The default storage engine is changed from MyISAM to InnoDB, in all builds except for the embedded server. In addition, the following system variables are changed: * innodb_file_per_table is enabled * innodb_strict_mode is enabled * innodb_file_format_name_update is changed to 'Barracuda' The test suite is changed so that tests that do not explicitly include the have_innodb.inc are run with --default-storage-engine=MyISAM. This is to ease the transition, so that most regression tests are run with the same engine as before. Some tests are disabled for the embedded server regression test, as the output of certain statements will be different that for the regular server (i.e SELECT @@default_storage_engine). This is to ease transition. mysql-test/mysql-test-run.pl: The regression test suite now adds a --default-storage-engine=MyISAM for all non-innodb tests. This behaviour can be controlled by the default-myisam switch in mysql-test-run mysql-test/t/bootstrap-master.opt: The bootstrap test can only be run without InnoDB as it starts several mysqld instances on the same datadir. This is possible with MyISAM, but not with InnoDB. storage/innobase/CMakeLists.txt: Build InnoDB per default storage/innobase/handler/ha_innodb.cc: Change default values for system variables Enable file_per_table Enable strict_mode Upgrade default file format to Barracuda
-
Joerg Bruehe authored
line exceeds the limit Merge the fix into "trunk-bugfixing".
-
Joerg Bruehe authored
line exceeds the limit Upmerge the fix from 5.1 to 5.5 ("trunk").
-
Joerg Bruehe authored
line exceeds the limit Upmerge the fix from 5.0 to 5.1
-
Joerg Bruehe authored
line exceeds the limit The number and/or names of our files for the main test suite (contents of "mysql-test/t/") now exceeds the command line length limit on AIX. Solve the problem by using separate "cp" commands for the various file name extensions.
-
Konstantin Osipov authored
-
Konstantin Osipov authored
-
Joerg Bruehe authored
to trunk-bugfixing, no contents changes (already done separate).
-
Joerg Bruehe authored
-
Joerg Bruehe authored
-
Vasil Dimov authored
-
Vasil Dimov authored
-
Vasil Dimov authored
-
Vasil Dimov authored
is going to be 1.1.1.
-
Jimmy Yang authored
and innodb_file_format_max two system variables. And this also fixes bug #53654 after 2nd shutdown innodb_file_format_check attains strange values. rb://366 approved by Marko
-
Sunny Bains authored
-
Alexander Nozdrin authored
-
Alexander Nozdrin authored
-
Sunny Bains authored
-
- 16 Jun, 2010 3 commits
-
-
Mats Kindahl authored
Incremental patch to fix plugin_dir from .../lib/plugin to .../lib/mysql/plugin.
-
Dmitry Lenev authored
TABLE_SHARE a class. Remove unused members in TABLE_SHARE.
-
Konstantin Osipov authored
-
- 15 Jun, 2010 2 commits
-
-
Joerg Bruehe authored
This is the fix for 5.5, where the behaviour on both installation and upgrade is changed: On installation, we do not start the server, to allow automated installs (which happen in some indeterminate machine status). If the server was stopped when the upgrade begins, we assume the administrator is taking manual action, so we do not start the (new) server at the end of the upgrade. We still install the start/stop script, so it will be started on reboot. support-files/mysql.spec.sh: In the "pre" section of the spec file, check the server status, and write the result to a file. In the "post" section, evaluate the status file, and start the server if it was running during status analysis. In 5.5, we do *not* start the server if there is no status file (which will happen on first installation, when there is no data directory yet).
-
Joerg Bruehe authored
This is the fix for 5.1, where only the behaviour on upgrade is changed: If the server was stopped when the upgrade begins, we assume the administrator is taking manual action, so we do not start the (new) server at the end of the upgrade. We still install the start/stop script, so it will be started on reboot. support-files/mysql.spec.sh: In the "pre" section of the spec file, check the server status, and write the result to a file. In the "post" section, evaluate the status file, and start the server if it was running during status analysis. In 5.1, we start the server if there is no status file (which will happen on first installation, when there is no data directory yet).
-