- 18 Apr, 2007 3 commits
- 13 Apr, 2007 1 commit
-
-
unknown authored
Change syntax to start manual gdb/ddd to avoid having to cd to the mysql-test directory before calling the command
-
- 10 Apr, 2007 7 commits
-
-
unknown authored
-
unknown authored
-
unknown authored
-
unknown authored
-
unknown authored
into pilot.blaudden:/home/msvensson/mysql/mysql-4.1-maint
-
unknown authored
-
unknown authored
into pilot.blaudden:/home/msvensson/mysql/mysql-4.1-maint client/mysqltest.c: Auto merged mysql-test/r/mysqltest.result: Auto merged mysql-test/t/mysqltest.test: Auto merged
-
- 07 Apr, 2007 1 commit
-
-
unknown authored
into mysql.com:/d2/hf/mrg/mysql-4.1-opt
-
- 05 Apr, 2007 2 commits
- 04 Apr, 2007 4 commits
- 03 Apr, 2007 1 commit
-
-
unknown authored
IN/BETWEEN predicates in sorting expressions. Wrong results may occur when the select list contains an expression with IN/BETWEEN predicate that differs from a sorting expression by an additional NOT only. Added the method Item_func_opt_neg::eq to compare correctly expressions containing [NOT] IN/BETWEEN. The eq method inherited from the Item_func returns TRUE when comparing 'a IN (1,2)' with 'a NOT IN (1,2)' that is not, of course, correct. mysql-test/r/order_by.result: Added a test case for bug #27532. mysql-test/t/order_by.test: Added a test case for bug #27532. sql/item_cmpfunc.cc: Fixed bug #27532. Added the method Item_func_opt_neg::eq to compare correctly expressions containing [NOT] IN/BETWEEN. The eq method inherited from the Item_func returns TRUE when comparing 'a IN (1,2)' with 'a NOT IN (1,2)' that is not, of course, correct. sql/item_cmpfunc.h: Added the method Item_func_opt_neg::eq to compare correctly expressions containing [NOT] IN/BETWEEN. The eq method inherited from the Item_func returns TRUE when comparing 'a IN (1,2)' with 'a NOT IN (1,2)' that is not, of course, correct.
-
- 02 Apr, 2007 2 commits
- 31 Mar, 2007 1 commit
-
-
unknown authored
into bk-internal.mysql.com:/data0/bk/mysql-4.1-opt
-
- 30 Mar, 2007 2 commits
-
-
unknown authored
Pushbuild fixes: - Make MAX_SEL_ARGS smaller (even 16K records_in_range() calls is more than it makes sense to do in typical cases) - Don't call sel_arg->test_use_count() if we've already allocated more than MAX_SEL_ARGs elements. The test will succeed but will take too much time for the test suite (and not provide much value). mysql-test/r/range.result: BUG#26624: high mem usage (crash) in range optimizer Pushbuild fixes: make the test go faster mysql-test/t/range.test: BUG#26624: high mem usage (crash) in range optimizer Pushbuild fixes: make the test go faster
-
unknown authored
into mysql.com:/home/kent/bk/tmp/mysql-4.1-build
-
- 29 Mar, 2007 4 commits
-
-
unknown authored
into pilot.blaudden:/home/msvensson/mysql/mysql-4.1-maint
-
unknown authored
into pilot.blaudden:/home/msvensson/mysql/mysql-4.1-maint
-
unknown authored
- GRANT and REVOKE statments didn't have the "updating" flag set and thus statements with a table specified would not replicate if slave filtering rules where turned on. For example "GRANT ... ON test.t1 TO ..." would not replicate. mysql-test/r/rpl_ignore_table.result: Add test results mysql-test/t/rpl_ignore_table.test: Add tests sql/sql_yacc.yy: Pass option TL_OPTION_UPDATING to 'add_table_to_list' when parsing a GRANT or REVOKE and a table specifier is found. This will set the property "updating" on the table and thus the slave filtering rules will be applied. Without setting updating the statement will be not replicated - since "it's not updating anything" - an optimization to quickly skip SELECT's and similar.
-
unknown authored
- Post-review fixes
-
- 28 Mar, 2007 10 commits
-
-
unknown authored
Thanks to Martin Friebe for finding and submitting a fix for this bug! A table with maximum number of key segments and maximum length key name would have a corrupted .frm file, due to an incorrect calculation of the complete key length. Now the key length is computed correctly (I hope) :-) MyISAM would reject a table with the maximum number of keys and the maximum number of key segments in all keys. It would allow one less than this total maximum. Now MyISAM accepts a table defined with the maximum. (This is a very minor issue.) myisam/mi_open.c: change >= to > in a comparison (i.e., error only if key_parts_in_table really is greater than MAX_KEY * MAX_KEY_SEG) mysql-test/r/create.result: Add test results for bug #26642 (create index corrupts table definition in .frm) mysql-test/t/create.test: Add test case for bug #26642 (create index corrupts table definition in .frm) sql/table.cc: In create_frm(), fix formula for key_length; it was too small by (keys * 2) bytes
-
unknown authored
into mysql.com:/home/psergey/mysql-4.1-bug26624-r2
-
unknown authored
- Added PARAM::alloced_sel_args where we count the # of SEL_ARGs created by SEL_ARG tree cloning operations. - Made the range analyzer to shortcut and not do any more cloning if we've already created MAX_SEL_ARGS SEL_ARG objects in cloning. - Added comments about space complexity of SEL_ARG-graph representation. mysql-test/r/range.result: BUG#26624: Testcase mysql-test/t/range.test: BUG#26624: Testcase
-
unknown authored
-
unknown authored
- Define Sql_alloc::operator new() as thow() so that C++ compiler handles NULL return values (there is no testcase as there is no portable way to set limit on the amount of memory that a process can allocate) sql/sql_list.h: BUG#26625: crash in range optimizer (out of mem) - Define Sql_alloc::operator new() as thow() so that C++ compiler handles NULL return values
-
unknown authored
into chilla.local:/home/mydev/mysql-4.1-axmrg
-
unknown authored
into chilla.local:/home/mydev/mysql-4.1-axmrg
-
unknown authored
into chilla.local:/home/mydev/mysql-4.1-axmrg sql/ha_myisam.cc: Auto merged
-
unknown authored
into chilla.local:/home/mydev/mysql-4.1-axmrg
-
unknown authored
into chilla.local:/home/mydev/mysql-4.1-bug24985 mysql-test/r/heap_btree.result: Bug#24985 - UTF8 ENUM primary key on MEMORY using BTREE causes incorrect duplicate entries Manual merge mysql-test/t/heap_btree.test: Bug#24985 - UTF8 ENUM primary key on MEMORY using BTREE causes incorrect duplicate entries Manual merge
-
- 27 Mar, 2007 2 commits
-
-
unknown authored
Don't use explicit calls to mysql-test-run in spec Makefile.am: Don't use explicit calls to mysql-test-run in spec support-files/mysql.spec.sh: Don't use explicit calls to mysql-test-run in spec
-
unknown authored
causes incorrect duplicate entries Keys for BTREE indexes on ENUM and SET columns of MEMORY tables with character set UTF8 were computed incorrectly. Many different column values got the same key value. Apart of possible performance problems, it made unique indexes of this type unusable because it rejected many different values as duplicates. The problem was that multibyte character detection was tried on the internal numeric column value. Many values were not identified as characters. Their key value became blank filled. Thanks to Alexander Barkov and Ramil Kalimullin for the patch, which sets the character set of ENUM and SET key segments to the pseudo binary character set. mysql-test/r/heap_btree.result: Bug#24985 - UTF8 ENUM primary key on MEMORY using BTREE causes incorrect duplicate entries Added test result. mysql-test/t/heap_btree.test: Bug#24985 - UTF8 ENUM primary key on MEMORY using BTREE causes incorrect duplicate entries Added test. sql/ha_heap.cc: Bug#24985 - UTF8 ENUM primary key on MEMORY using BTREE causes incorrect duplicate entries Set key segment charset to my_charset_bin for ENUM and SET columns.
-