- 15 Aug, 2006 12 commits
-
-
evgen@moonbone.local authored
into moonbone.local:/work/15950-bug-5.0-opt-mysql
-
sergefp@mysql.com authored
into mysql.com:/home/psergey/mysql-5.0-opt-bug21282-r2
-
sergefp@mysql.com authored
-
sergefp@mysql.com authored
In fix for BUG#15872, a condition of type "t.key NOT IN (c1, .... cN)" where N>1000, was incorrectly converted to (-inf < X < c_min) OR (c_max < X) Now this conversion is removed, we dont produce any range lists for such conditions.
-
evgen@moonbone.local authored
This bug is a side-effect of bug fix #16377. NOW() is optimized in BETWEEN to integer constants to speed up query execution. When view is being created it saves already modified query and thus becomes wrong. The agg_cmp_type() function now substitutes constant result DATE/TIME functions for their results only if the current query isn't CREATE VIEW or SHOW CREATE VIEW.
-
sergefp@mysql.com authored
BUG#21077: Possible crash caused by invalid sequence of handler::* calls: The crash was caused by invalid sequence of handler::** calls: ha_smth->index_init(); ha_smth->index_next_same(); (2) (2) is an invalid call as it was not preceeded by any 'scan setup' call like index_first() or index_read(). The cause was that QUICK_SELECT::reset() didn't "fully reset" the quick select- current QUICK_RANGE wasn't forgotten, and quick select might attempt to continue reading the range, which would result in the above mentioned invalid sequence of handler calls. 5.x versions are not affected by the bug - they already have the missing "range=NULL" clause.
-
gkodinov/kgeorge@macbook.gmz authored
- undeterminstic tests fixed
-
gkodinov/kgeorge@rakia.(none) authored
on a second table in a join - undeterministic output of the test case removed.
-
gkodinov/kgeorge@rakia.(none) authored
into rakia.(none):/home/kgeorge/mysql/autopush/B21159-5.0-opt
-
gkodinov/kgeorge@rakia.(none) authored
into rakia.(none):/home/kgeorge/mysql/autopush/B21174-5.0-opt
-
gkodinov/kgeorge@rakia.(none) authored
into rakia.(none):/home/kgeorge/mysql/autopush/B21159-5.0-opt
-
gkodinov/kgeorge@macbook.gmz authored
Disable const propagation for Item_hex_string. This must be done because Item_hex_string->val_int() is not the same as (Item_hex_string->val_str() in BINARY column)->val_int(). We cannot simply disable the replacement in a particular context ( e.g. <bin_col> = <int_col> AND <bin_col> = <hex_string>) since Items don't know the context they are in and there are functions like IF (<hex_string>, 'yes', 'no'). Note that this will disable some valid cases as well (e.g. : <bin_col> = <hex_string> AND <bin_col2> = <bin_col>) but there's no way to distinguish the valid cases without having the Item's parent say something like : Item->set_context(Item::STRING_RESULT) and have all the Items that contain other Items do that consistently.
-
- 14 Aug, 2006 3 commits
-
-
gkodinov/kgeorge@macbook.gmz authored
optimizer does not honor IGNORE INDEX - Allow an index to be used for sorting the table instead of filesort only if it is not disabled by IGNORE INDEX.
-
gkodinov/kgeorge@rakia.(none) authored
into rakia.(none):/home/kgeorge/mysql/autopush/B21302-5.0-opt
-
gkodinov/kgeorge@macbook.gmz authored
table in a join The optimizer removes redundant columns in ORDER BY. It is considering redundant every reference to const table column, e.g b in : create table t1 (a int, b int, primary key(a)); select 1 from t1 order by b where a = 1 But it must not remove references to const table columns if the const table is an outer table because there still can be 2 values : the const value and NULL. e.g.: create table t1 (a int, b int, primary key(a)); select t2.b c from t1 left join t1 t2 on (t1.a = t2.a and t2.a = 5) order by c;
-
- 11 Aug, 2006 3 commits
-
-
evgen@moonbone.local authored
into moonbone.local:/work/tmp_merge-5.0-opt-mysql
-
svoj@may.pils.ru authored
-
svoj@may.pils.ru authored
into may.pils.ru:/home/svoj/devel/mysql/BUG7391/mysql-5.0
-
- 10 Aug, 2006 4 commits
-
-
cmiller@zippy.cornsilk.net authored
-
gkodinov/kgeorge@macbook.gmz authored
-
cmiller@zippy.cornsilk.net authored
-
cmiller@zippy.cornsilk.net authored
into zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.0
-
- 09 Aug, 2006 3 commits
-
-
svoj@may.pils.ru authored
into may.pils.ru:/home/svoj/devel/mysql/BUG20060/mysql-5.0
-
svoj@may.pils.ru authored
Problem described in this bug report affects MyISAM tables only. Running mysqld --flush instructs mysqld to sync all changes to disk after each SQL statement. It worked well for INSERT and DELETE statements, but it did sync for UPDATE only in case if there was index change (change of colum that has an index). If no updated column has an index, data wasn't synced to disk. This fix makes UPDATE statement to sync data to disk even if there is no index change (that is only data change) and mysqld is run with --flush option.
-
evgen@sunlight.local authored
After merge fix
-
- 08 Aug, 2006 3 commits
-
-
evgen@sunlight.local authored
into sunlight.local:/local_work/leak_fix
-
evgen@sunlight.local authored
into sunlight.local:/local_work/leak_fix
-
evgen@sunlight.local authored
Correct memory leak fix
-
- 07 Aug, 2006 1 commit
-
-
evgen@sunlight.local authored
Memory leak fix
-
- 06 Aug, 2006 3 commits
-
-
evgen@sunlight.local authored
into sunlight.local:/local_work/leak_fix
-
evgen@sunlight.local authored
into sunlight.local:/local_work/leak_fix
-
evgen@sunlight.local authored
Memory leak fix
-
- 03 Aug, 2006 8 commits
-
-
kostja@bodhi.local authored
-
kostja@bodhi.local authored
-
msvensson@neptunus.(none) authored
-
msvensson@neptunus.(none) authored
now takes mbmaxlen into account when calculating max_length of new field.
-
svoj@may.pils.ru authored
into may.pils.ru:/home/svoj/devel/mysql/BUG7391/mysql-4.1
-
msvensson@neptunus.(none) authored
- Backport patch from 5.0
-
msvensson@neptunus.(none) authored
into neptunus.(none):/home/msvensson/mysql/mysql-5.0-maint
-
msvensson@neptunus.(none) authored
-