- 18 May, 2008 1 commit
-
-
gkodinov/kgeorge@magare.gmz authored
into magare.gmz:/home/kgeorge/mysql/work/merge-5.1-bugteam
-
- 17 May, 2008 1 commit
-
-
holyfoot/hf@mysql.com/hfmain.(none) authored
temporary variables of 'long' types were used to store ulong values, that causes init_key_cache to receive distorted parameters
-
- 16 May, 2008 24 commits
-
-
cmiller@zippy.cornsilk.net authored
into zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.0-bugteam
-
cmiller@zippy.cornsilk.net authored
into zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.0-bugteam
-
cmiller@zippy.cornsilk.net authored
into zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.1-bugteam
-
gkodinov/kgeorge@magare.gmz authored
updated the testcase for bug 36011
-
gkodinov/kgeorge@magare.gmz authored
into magare.gmz:/home/kgeorge/mysql/work/B36011-5.1-bugteam
-
gkodinov/kgeorge@magare.gmz authored
into magare.gmz:/home/kgeorge/mysql/autopush/B36011-take2-5.0-bugteam
-
cmiller@zippy.cornsilk.net authored
-
cmiller@zippy.cornsilk.net authored
into zippy.cornsilk.net:/home/cmiller/work/mysql/bug36570/my51-bug36570
-
cmiller@zippy.cornsilk.net authored
-
cmiller@zippy.cornsilk.net authored
master also, so that we can visually see the slave is the same.
-
mats@mats-laptop.(none) authored
into mats-laptop.(none):/home/bk/b36197-mysql-5.1-bugteam
-
mats@mats-laptop.(none) authored
-
gkodinov/kgeorge@magare.gmz authored
with dependent subqueries An IN subquery is executed on EXPLAIN when it's not correlated. If the subquery required a temporary table for its execution not all the internal structures were restored from pointing to the items of the temporary table to point back to the items of the subquery. Fixed by restoring the ref array when a temp tables were used in executing the IN subquery during EXPLAIN EXTENDED.
-
davi@endora.local authored
into mysql.com:/Users/davi/mysql/mysql-5.0-bugteam
-
davi@endora.local authored
into mysql.com:/Users/davi/mysql/mysql-5.1-bugteam
-
cmiller@zippy.cornsilk.net authored
into zippy.cornsilk.net:/home/cmiller/work/mysql/bug36570/my51-bug36570
-
cmiller@zippy.cornsilk.net authored
-
mats@mats-laptop.(none) authored
into mats-laptop.(none):/home/bkroot/mysql-5.1-bugteam
-
pcrews@pcrews-mac-local.local authored
into pcrews-mac-local.local:/Users/pcrews/usr/local/bin/data0/build_work/test_fix/mysql-5.1-bugteam_35744
-
mats@mats-laptop.(none) authored
into mats-laptop.(none):/home/bkroot/mysql-5.1-bugteam
-
-
mats@mats-laptop.(none) authored
into mats-laptop.(none):/home/bkroot/mysql-5.1-bugteam
-
gshchepa/uchum@host.loc authored
into host.loc:/work/bk/5.0-bugteam
-
gshchepa/uchum@host.loc authored
into host.loc:/work/bk/5.1-bugteam
-
- 15 May, 2008 11 commits
-
-
cmiller@zippy.cornsilk.net authored
into zippy.cornsilk.net:/home/cmiller/work/mysql/bug36570/my51-bug36570
-
pcrews@pcrews-mac-local.local authored
into pcrews-mac-local.local:/Users/pcrews/usr/local/bin/data0/build_work/test_fix/mysql-5.1-bugteam_35744
-
cmiller@zippy.cornsilk.net authored
slave The stored-routine code took the contents of the (lowest) parser and copied it directly to the binlog, which causes problems if there is a special case of interpretation at the parser level -- which there is, in the "/*!VER */" comments. The trailing "*/" caused errors on the slave, naturally. Now, since by that point we have /properly/ created parse-tree (as the rest of the server should do!) for the stored-routine CREATE, we can construct a perfect statement from that information, instead of writing uncertain information from an unknown parser state. Fortunately, there's already a function nearby that does exactly that. --- Update for Bug#36570. Qualify routine names with db name when writing to the binlog ONLY if the source text is qualified.
-
sven@riska.(none) authored
into riska.(none):/home/sven/bk/b36433-rpl_insert_id/5.1-bugteam
-
mats@mats-laptop.(none) authored
into mats-laptop.(none):/home/bk/b36197-mysql-5.1-bugteam
-
mleich@five.local.lan authored
into five.local.lan:/work/trees/mysql-5.1-bugteam-src-clean
-
pcrews@pcrews-mac-local.local authored
into pcrews-mac-local.local:/Users/pcrews/usr/local/bin/data0/build_work/test_fix/mysql-5.1-bugteam_35744
-
mleich@five.local.lan authored
Bug#28563 Test suite "jp" fails completely - The main goal of this fix is to make the "jp" suite runnable in general and to make it more robust for use in pushbuild under build team conditions. - It was decided to fix the remaining heavy issues within the architecture of this test later (-> WL 4327 Redesign the 'jp' testsuite for build team testing conditions) Only the test jp_trim_sjis got some significant improvements of its architecture (Just as proof of concept for the other tests). - Tests suffering from Bug 36597 Testsuite "jp": Suspicious results for some tests (unexpected result sets) were disabled - *.opt files were used to avoid differences on OS (Windows) because of case sensitive tablenames within the tests
-
sven@riska.(none) authored
Problem: If INSERT is immediately followed by SELECT in another thread, the newly inserted rows may not be returned by the SELECT statement, if ENGINE=myisam and @@concurrent_insert=1. This caused sporadic errors in rpl_insert_id. Fix: The test now uses ENGINE=$engine_type when creating tables (so that innodb is used). It also turns off @@concurrent_insert around the critical place, so that it works if someone in the future writes a test that sets $engine_type=myisam before sourcing extra/rpl_tests/rpl_insert_id.test. It also adds ORDER BY to all SELECTs so that the result is deterministic.
-
cmiller@zippy.cornsilk.net authored
into zippy.cornsilk.net:/home/cmiller/work/mysql/bug36570/my51-bug36570
-
gkodinov/kgeorge@magare.gmz authored
-
- 14 May, 2008 3 commits
-
-
cmiller@zippy.cornsilk.net authored
slave The stored-routine code took the contents of the (lowest) parser and copied it directly to the binlog, which causes problems if there is a special case of interpretation at the parser level -- which there is, in the "/*!VER */" comments. The trailing "*/" caused errors on the slave, naturally. Now, since by that point we have /properly/ created parse-tree (as the rest of the server should do!) for the stored-routine CREATE, we can construct a perfect statement from that information, instead of writing uncertain information from an unknown parser state. Fortunately, there's already a function nearby that does exactly that.
-
gkodinov/kgeorge@magare.gmz authored
-
gkodinov/kgeorge@magare.gmz authored
into magare.gmz:/home/kgeorge/mysql/work/merge-5.1-bugteam
-