- 30 Sep, 2006 1 commit
-
-
dlenev@mockturtle.local authored
into mockturtle.local:/home/dlenev/src/mysql-5.0-bg20670-2
-
- 29 Sep, 2006 3 commits
-
-
dlenev@mockturtle.local authored
into mockturtle.local:/home/dlenev/src/mysql-5.0-rt-merge
-
dlenev@mockturtle.local authored
-
dlenev@mockturtle.local authored
into mockturtle.local:/home/dlenev/src/mysql-5.0-rt-merge
-
- 28 Sep, 2006 2 commits
-
-
dlenev@mockturtle.local authored
create_tmp_table()". The fix for bug 21787 "COUNT(*) + ORDER BY + LIMIT returns wrong result" introduced valgrind warnings which occured during execution of information_schema.test and sp-prelocking.test in version 5.0. There were no user visible effects. The latter fix made create_tmp_table() dependant on THD::lex::current_select value. Valgrind warnings occured when this function was executed and THD::lex::current_select member pointed to uninitialized SELECT_LEX instance. This fix tries to remove this dependancy by moving some logic outside of create_tmp_table() function.
-
dlenev@mockturtle.local authored
into mockturtle.local:/home/dlenev/src/mysql-4.1-runtime
-
- 27 Sep, 2006 7 commits
-
-
andrey@example.com authored
into example.com:/work/mysql-5.0-runtime
-
andrey@example.com authored
There was possible stack overrun in an edge case which handles invalid body of a SP in mysql.proc . That should be case when mysql.proc has been changed manually. Though, due to bug 21513, it can be exploited without having access to mysql.proc only being able to create a stored routine.
-
gluh@mysql.com/gluh.(none) authored
-
gluh@mysql.com/gluh.(none) authored
-
gluh@mysql.com/gluh.(none) authored
into mysql.com:/home/gluh/MySQL/Merge/5.0
-
gluh@mysql.com/gluh.(none) authored
-
kroki/tomash@moonlight.intranet authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug21414
-
- 26 Sep, 2006 2 commits
-
-
msvensson@neptunus.(none) authored
into neptunus.(none):/home/msvensson/mysql/mysql-5.0-runtime
-
joerg@trift2. authored
into trift2.:/MySQL/M50/push-5.0
-
- 25 Sep, 2006 1 commit
-
-
msvensson@neptunus.(none) authored
Remove race situations that occur when removing pidfiles. Primarily each process should remove its own pidfile, secondly it should be removed by the process that created it and _only_ if it's certain the process is dead. Third, mysql-test-run.pl will remove the pidfile when process has been killed. - Set state of an instance to STARTING _before_ calling instance->start() - Check that pidfile of instance has been created before changing STARTING => STARTED - Only remove the pidfile if IM kills an instance with SIGKILL, otherwise the instance will remove it itself
-
- 24 Sep, 2006 2 commits
-
-
into mysql.com:/Users/kent/mysql/bk/mysql-5.0
-
Filter out plain -O and Sun C/C++ style optimization flags, -xO<level> Filter out icc specific options from cflags/libs(_r)
-
- 23 Sep, 2006 5 commits
-
-
into mysql.com:/users/lthalmann/bk/MERGE/mysql-5.0-merge
-
into mysql.com:/users/lthalmann/bk/MERGE/mysql-5.0-merge
-
into mysql.com:/users/lthalmann/bk/MERGE/mysql-4.1-merge
-
into mysql.com:/users/lthalmann/bk/MERGE/mysql-5.0-merge
-
into mysql.com:/users/lthalmann/bk/MERGE/mysql-4.1-merge
-
- 22 Sep, 2006 2 commits
-
-
georg@lmy002.wdf.sap.corp authored
-
georg@lmy002.wdf.sap.corp authored
-
- 21 Sep, 2006 10 commits
-
-
joerg@trift2. authored
into trift2.:/MySQL/M50/push-5.0
-
joerg@trift2. authored
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-5.0-toteam
-
joerg@trift2. authored
into trift2.:/MySQL/M50/push-5.0
-
-
into mysql.com:/users/lthalmann/bk/MERGE/mysql-5.0-merge
-
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-5.0-toteam
-
dlenev@mockturtle.local authored
this key does not stop" (version for 5.0 only). UPDATE statement which WHERE clause used key and which invoked trigger that modified field in this key worked indefinetely. This problem occured because in cases when UPDATE statement was executed in update-on-the-fly mode (in which row is updated right during evaluation of select for WHERE clause) the new version of the row became visible to select representing WHERE clause and was updated again and again. We already solve this problem for UPDATE statements which does not invoke triggers by detecting the fact that we are going to update field in key used for scanning and performing update in two steps, during the first step we gather information about the rows to be updated and then doing actual updates. We also do this for MULTI-UPDATE and in its case we even detect situation when such fields are updated in triggers (actually we simply assume that we always update fields used in key if we have before update trigger). The fix simply extends this check which is done in check_if_key_used()/ QUICK_SELECT_I::check_if_keys_used() routine/method in such way that it also detects cases when field used in key is updated in trigger. As nice side-effect we have more precise and thus more optimal perfomance-wise check for the MULTI-UPDATE. Also check_if_key_used()/QUICK_SELECT_I::check_if_keys_used() were renamed to is_key_used()/QUICK_SELECT_I::is_keys_used() in order to better reflect that boolean predicate. Note that this check is implemented in much more elegant way in 5.1
-
-
- 20 Sep, 2006 5 commits
-
-
into mysql.com:/users/lthalmann/bk/MERGE/mysql-5.0-merge
-
-
into mysql.com:/users/lthalmann/bk/MERGE/mysql-5.0-merge
-
into mysql.com:/users/lthalmann/bk/MERGE/mysql-4.1-merge
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-4.1-bug14400-monty
-