- 26 Jun, 2006 4 commits
-
-
jimw@mysql.com authored
When building the UPDATE query to send to the remote server, the federated storage engine built the query incorrectly if it was updating a field to be NULL. Thanks to Bjrn Steinbrink for an initial patch for the problem.
-
anozdrin@mysql.com authored
into mysql.com:/home/alik/MySQL/devel/5.0-rt
-
tnurnberg@mysql.com authored
into mysql.com:/home/tnurnberg/mysql-5.0-maint-18462
-
elliot@mysql.com authored
into mysql.com:/data0/bk/mysql-5.0-maint
-
- 24 Jun, 2006 2 commits
-
-
knielsen@mysql.com authored
into mysql.com:/data0/knielsen/tmp-5.0
-
knielsen@mysql.com authored
Sometimes the helper connection (that is watching for the main connection to time out) would itself time out first, causing the test to fail.
-
- 23 Jun, 2006 9 commits
-
-
iggy@mysql.com authored
into mysql.com:/mnt/storeage/mysql-5.0-maint_bug20616
-
iggy@mysql.com authored
-
evgen@moonbone.local authored
After merge fix
-
elliot@mysql.com authored
-
knielsen@mysql.com authored
into mysql.com:/usr/local/mysql/tmp-5.0
-
knielsen@mysql.com authored
The problem was a call to convert_dirname() with a destination buffer that did not have room for the trailing slash added by that function. This could cause the instance manager to crash in some cases.
-
evgen@moonbone.local authored
into moonbone.local:/work/tmp_merge-5.0-opt-mysql
-
evgen@moonbone.local authored
into moonbone.local:/work/tmp_merge-5.0-opt-mysql
-
bar@mysql.com authored
An UNIQUE KEY consisting of NOT NULL columns was displayed as PRIMARY KEY in "DESC t1". According to the code, that was intentional behaviour for some reasons unknown to me. This code was written before bitkeeper time, so I cannot check who and why made this. After discussing on dev-public, a decision was made to remove this code
-
- 22 Jun, 2006 13 commits
-
-
kent@mysql.com authored
Disable the simplistic auto dependency scan for test/bench (bug#20078)
-
tnurnberg@mysql.com authored
into mysql.com:/home/tnurnberg/mysql-5.0-maint-19409
-
konstantin@mysql.com authored
into mysql.com:/opt/local/work/mysql-5.0-runtime
-
pekka@clam.ndb.mysql.com authored
into clam.ndb.mysql.com:/space/pekka/ndb/version/my50-bug18781
-
tnurnberg@mysql.com authored
- The setting of "ENV{'TZ'}" doesn't affect the timezone used by MySQL Server on Windows. - Explicitly set timezone in test cases before doing UTC/localtime conversions so tests produce deterministic results
-
tnurnberg@mysql.com authored
- The setting of "ENV{'TZ'}" doesn't affect the timezone used by MySQL Server on Windows. - Explicitly set timezone to "+03:00" in test case before doing the calculatiosn to check that there is three hours difference between utc and local time. (Magnus' fix)
-
kroki@mysql.com authored
into mysql.com:/home/tomash/src/mysql_ab/mysql-5.0-bug15811
-
konstantin@mysql.com authored
into mysql.com:/opt/local/work/mysql-5.0-runtime
-
kroki@mysql.com authored
into mysql.com:/home/tomash/src/mysql_ab/mysql-5.0-bug15811
-
konstantin@mysql.com authored
with PREPARE fails with weird error". More generally, re-executing a stored procedure with a complex SP cursor query could lead to a crash. The cause of the problem was that SP cursor queries were not optimized properly at first execution: their parse tree belongs to sp_instr_cpush, not sp_instr_copen, and thus the tree was tagged "EXECUTED" when the cursor was declared, not when it was opened. This led to loss of optimization transformations performed at first execution, as sp_instr_copen saw that the query is already "EXECUTED" and therefore either not ran first-execution related blocks or wrongly rolled back the transformations caused by first-execution code. The fix is to update the state of the parsed tree only when the tree is executed, as opposed to when the instruction containing the tree is executed. Assignment if i->state is moved to reset_lex_and_exec_core.
-
kroki@mysql.com authored
The problem was in redundant calls to strlen() in string functions, where we may then return after checking only the small number of characters. No test case is provided since it's a performance fix.
-
evgen@moonbone.local authored
into moonbone.local:/work/tmp_merge-5.0-opt-mysql
-
cmiller@zippy.(none) authored
into zippy.(none):/home/cmiller/work/mysql/mysql-5.0__bug19904
-
- 21 Jun, 2006 12 commits
-
-
evgen@moonbone.local authored
into moonbone.local:/work/tmp_merge-5.0-opt-mysql
-
into a193-229-222-105.elisa-laajakaista.fi:/home/jani/mysql-5.0
-
evgen@moonbone.local authored
-
evgen@moonbone.local authored
into moonbone.local:/work/tmp_merge-5.0-opt-mysql
-
evgen@moonbone.local authored
into moonbone.local:/work/tmp_merge-4.1-opt-mysql
-
evgen@moonbone.local authored
This bug in Field_string::cmp resulted in a wrong comparison with keys in partial indexes over multi-byte character fields. Given field a is declared as a varchar(16) collate utf8_unicode_ci INDEX(a(4)) gives us an example of such an index. Wrong key comparisons could lead to wrong result sets if the selected query execution plan used a range scan by a partial index over a utf8 character field. This also caused wrong results in many other cases.
-
mats@mysql.com authored
into mysql.com:/home/bk/fix-mysql-5.0
-
into a193-229-222-105.elisa-laajakaista.fi:/home/jani/mysql-5.0
-
bk://localhost:5559
into a193-229-222-105.elisa-laajakaista.fi:/home/jani/mysql-5.0
-
jani@ua141d10.elisa.omakaista.fi authored
-
cmiller@zippy.(none) authored
into zippy.(none):/home/cmiller/work/mysql/mysql-5.0-maint
-
svoj@may.pils.ru authored
into may.pils.ru:/home/svoj/devel/mysql/BUG20357/mysql-5.0
-