- 23 Nov, 2007 5 commits
-
-
ssh://bk-internal.mysql.com//home/bk/mysql-5.1-optkaa@polly.(none) authored
into polly.(none):/home/kaa/src/opt/mysql-5.1-opt
-
kaa@polly.(none) authored
into polly.(none):/home/kaa/src/opt/mysql-5.1-opt
-
gkodinov/kgeorge@magare.gmz authored
-
gkodinov/kgeorge@magare.gmz authored
into magare.gmz:/home/kgeorge/mysql/work/merge-5.1-opt
-
kaa@polly.(none) authored
change the size of core files. Suppress the 'setrlimit could not change the size of the core files' warning in mysql-test-run. We do not want core files on some of the PushBuild hosts, and PushBuild itself does not set --core-files, so that warning is expected.
-
- 22 Nov, 2007 12 commits
-
-
evgen@moonbone.local authored
Fix for the bug#31048 for 64bit platforms. subselect.test, subselect.result: Corrected text case for the bug#31048.
-
gshchepa/uchum@gleb.loc authored
into gleb.loc:/work/bk/5.0-opt
-
gkodinov/kgeorge@magare.gmz authored
into magare.gmz:/home/kgeorge/mysql/autopush/B31171-5.1-opt
-
kaa@polly.(none) authored
into polly.(none):/home/kaa/src/opt/mysql-5.1-opt
-
kaa@polly.(none) authored
into polly.(none):/home/kaa/src/opt/mysql-5.0-opt
-
kaa@polly.(none) authored
into polly.(none):/home/kaa/src/opt/bug32221/my51-bug31445
-
kaa@polly.(none) authored
We do not have any executables in libmysql/release/ anymore.
-
gkodinov/kgeorge@magare.gmz authored
into magare.gmz:/home/kgeorge/mysql/autopush/B31171-5.1-opt
-
kaa@polly.(none) authored
into polly.(none):/home/kaa/src/opt/mysql-5.1-opt
-
kaa@polly.(none) authored
into polly.(none):/home/kaa/src/opt/mysql-5.0-opt
-
kaa@polly.(none) authored
into polly.(none):/home/kaa/src/opt/bug32221/my51-bug31445
-
gkodinov/kgeorge@magare.gmz authored
into magare.gmz:/home/kgeorge/mysql/autopush/B31171-5.1-opt
-
- 21 Nov, 2007 6 commits
-
-
gshchepa/uchum@gleb.loc authored
is_last_prefix <= 0, file .\opt_range.cc. SELECT ... GROUP BY bit field failed with an assertion if the bit length of that field was not divisible by 8.
-
gkodinov/kgeorge@macbook.gmz authored
"Table is already up to date" vs. "OK" On MacOSX 10.5 when you cast something to "bool" (the built in C type) it takes values 0 or 1 instead of 0-255 as it seems to be on older compilers. Fixed by removing the typecast (not needed). No test case needed : there are tests that test it.
-
gkodinov/kgeorge@magare.gmz authored
-
gkodinov/kgeorge@magare.gmz authored
into magare.gmz:/home/kgeorge/mysql/work/B30788-5.1-opt
-
gkodinov/kgeorge@magare.gmz authored
into magare.gmz:/home/kgeorge/mysql/autopush/B30788-5.0-opt
-
gkodinov/kgeorge@magare.gmz authored
Index lookup does not always guarantee that we can simply remove the relevant conditions from the WHERE clause. Reasons can be e.g. conversion errors, partial indexes etc. The optimizer was removing these parts of the WHERE condition without any further checking. This leads to "false positives" when using indexes. Fixed by checking the index reference conditions (using WHERE) when using indexes with sub-queries.
-
- 20 Nov, 2007 14 commits
-
-
evgen@moonbone.local authored
into moonbone.local:/work/31048-bug-5.0-opt-mysql
-
evgen@moonbone.local authored
Additional stack check for the bug#31048.
-
gshchepa/uchum@gleb.loc authored
into gleb.loc:/work/bk/5.0-opt
-
gshchepa/uchum@gleb.loc authored
8bit escape characters, termination and enclosed characters were silently ignored by SELECT INTO query, but LOAD DATA INFILE algorithm is 8bit-clean, so data was corrupted during encoding.
-
sergefp@foxhole.(none) authored
into mysql.com:/home/psergey/mysql-5.1-bug30573
-
holyfoot/hf@hfmain.(none) authored
into mysql.com:/home/hf/work/mysql-5.0-opt
-
holyfoot/hf@mysql.com/hfmain.(none) authored
-
holyfoot/hf@mysql.com/hfmain.(none) authored
-
holyfoot/hf@hfmain.(none) authored
into mysql.com:/home/hf/work/31868/my50-31868
-
holyfoot/hf@hfmain.(none) authored
into mysql.com:/home/hf/work/31868/my51-31868
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/home/hf/work/31868/my41-31868
-
holyfoot/hf@hfmain.(none) authored
into mysql.com:/home/hf/work/31868/my51-31868
-
holyfoot/hf@hfmain.(none) authored
into mysql.com:/home/hf/work/31868/my51-31868
-
sergefp@mysql.com authored
The problem: ha_partition::read_range_first() could return a record that is outside of the scanned range. If that record happened to be in the next subsequent range, it would satisfy the WHERE and appear in the output twice. (we would get it the second time when scanning the next subsequent range) Fix: Made ha_partition::read_range_first() check if the returned recod is within the scanned range, like other read_range_first() implementations do.
-
- 19 Nov, 2007 3 commits
-
-
evgen@moonbone.local authored
into moonbone.local:/work/31048-bug-5.0-opt-mysql
-
evgen@moonbone.local authored
into moonbone.local:/work/31048-bug-5.0-opt-mysql
-
evgen@moonbone.local authored
into moonbone.local:/work/30384-bug-5.0-opt-mysql
-