- 28 Sep, 2006 1 commit
-
-
kroki/tomash@moonlight.intranet authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug21081
-
- 27 Sep, 2006 2 commits
-
-
kroki/tomash@moonlight.intranet authored
Re-execution of a parametrized prepared statement or a stored routine with a SELECT that use LEFT JOIN with second table having only one row could yield incorrect result. The problem appeared only for left joins with second table having only one row (aka const table) and equation conditions in ON or WHERE clauses that depend on the argument passed. Once the condition was false for second const table, a NULL row was created for it, and any field involved got NULL-value flag, which then was never reset. The cause of the problem was that Item_field::null_value could be set without being reset for re-execution. The solution is to reset Item_field::null_value in Item_field::cleanup().
-
kroki/tomash@moonlight.intranet authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-bug21414
-
- 26 Sep, 2006 1 commit
-
-
msvensson@neptunus.(none) authored
into neptunus.(none):/home/msvensson/mysql/mysql-5.0-runtime
-
- 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
-
- 12 Sep, 2006 1 commit
-
-
kroki/tomash@moonlight.intranet authored
The problem was that if after FLUSH TABLES WITH READ LOCK the user issued DROP/ALTER PROCEDURE/FUNCTION the operation would fail (as expected), but after UNLOCK TABLE any attempt to execute the same operation would lead to the error 1305 "PROCEDURE/FUNCTION does not exist", and an attempt to execute any stored function will also fail. This happened because under FLUSH TABLES WITH READ LOCK we couldn't open and lock mysql.proc table for update, and this fact was erroneously remembered by setting mysql_proc_table_exists to false, so subsequent statements believed that mysql.proc doesn't exist, and thus that there are no functions and procedures in the database. As a solution, we remove mysql_proc_table_exists flag completely. The reason is that this optimization didn't work most of the time anyway. Even if open of mysql.proc failed for some reason when we were trying to call a function or a procedure, we were setting mysql_proc_table_exists back to true to force table reopen for the sake of producing the same error message (the open can fail for number of reasons). The solution could have been to remember the reason why open failed, but that's a lot of code for optimization of a rare case. Hence we simply remove this optimization.
-
- 11 Sep, 2006 1 commit
-
-
anozdrin/alik@alik. authored
into alik.:/mnt/raid/alik/MySQL/devel/5.0-rt-merged
-
- 08 Sep, 2006 4 commits
-
-
anozdrin/alik@alik. authored
to start instance manager. The problem was that if IM failed to start, test suite aborts. The fix is to mark current test as failed, and continue running test suite. The fix affects only test suite.
-
anozdrin/alik@alik. authored
The patch affects only test suite and has the following changes: 1. On starting Instance Manager -- added code for waiting for guarded mysqld instances to create PID files; 2. Polishing; 3. Move IM-related operations out of mtr_process.pl into new dedicated for IM file -- mtr_im.pl
-
gluh@mysql.com/gluh.(none) authored
into mysql.com:/home/gluh/MySQL/Merge/5.0
-
gluh@mysql.com/gluh.(none) authored
-
- 07 Sep, 2006 5 commits
-
-
joerg@trift2. authored
-
joerg@trift2. authored
into trift2.:/M50/push-5.0
-
joerg@trift2. authored
To be pushed to both the cloned 5.0.25 and the general 5.0 tree.
-
gluh@mysql.com/gluh.(none) authored
-
gluh@mysql.com/gluh.(none) authored
into mysql.com:/home/gluh/MySQL/Merge/5.0
-
- 06 Sep, 2006 4 commits
-
-
cmiller@zippy.cornsilk.net authored
into zippy.cornsilk.net:/home/cmiller/work/mysql/mysql-5.0-maint
-
-
anozdrin/alik@alik. authored
into alik.:/mnt/raid/alik/MySQL/devel/5.0-rt
-
jonas@perch.ndb.mysql.com authored
into perch.ndb.mysql.com:/home/jonas/src/mysql-5.0-ndb
-
- 05 Sep, 2006 2 commits
-
-
guilhem@gbichot3.local authored
In 5.0 we made LOAD DATA INFILE autocommit in all engines, while only NDB wanted that. Users and trainers complained that it affected InnoDB and was a change compared to 4.1 where only NDB autocommitted. To revert to the behaviour of 4.1, we move the autocommit logic out of mysql_load() into ha_ndbcluster::external_lock(). The result is that LOAD DATA INFILE commits all uncommitted changes of NDB if this is an NDB table, its own changes if this is an NDB table, but does not affect other engines. Note: even though there is no "commit the full transaction at end" anymore, LOAD DATA INFILE stays disabled in routines (re-entrency problems per a comment of Pem). Note: ha_ndbcluster::has_transactions() does not give reliable results because it says "yes" even if transactions are disabled in this engine...
-
anozdrin/alik@alik. authored
into alik.:/mnt/raid/alik/MySQL/devel/5.0-rt
-
- 04 Sep, 2006 11 commits
-
-
jonas@perch.ndb.mysql.com authored
into perch.ndb.mysql.com:/home/jonas/src/mysql-5.0-ndb
-
jonas@perch.ndb.mysql.com authored
into perch.ndb.mysql.com:/home/jonas/src/50-work
-
jonas@perch.ndb.mysql.com authored
fix deadlock if master switches log file in parallell with "show master logs"
-
msvensson@neptunus.(none) authored
into neptunus.(none):/home/msvensson/mysql/mysql-5.0
-
msvensson@neptunus.(none) authored
into neptunus.(none):/home/msvensson/mysql/mysql-5.0
-
msvensson@neptunus.(none) authored
into neptunus.(none):/home/msvensson/mysql/mysql-5.0
-
msvensson@neptunus.(none) authored
Fix problem where mysql-test-run.pl fails to start up the mysqld after a failed test. Shows up on win hosts where one failed test case make subsequent ones fails with error "Could not open connection 'default': 2003 Can't connect to MySQL server on 'localhost'"
-
msvensson@neptunus.(none) authored
into neptunus.(none):/home/msvensson/mysql/mysql-5.0
-
tnurnberg@maint1.mysql.com authored
into maint1.mysql.com:/data/localhome/tnurnberg/my50-21913
-
into salvation.intern.azundris.com:/home/tnurnberg/21913/my50-21913 21913: DATE_FORMAT() Crashes mysql server if I use it through mysql-connector-j driver. Variable character_set_results can legally be NULL (for "no conversion.") This could result in a NULL deref that crashed the server. Fixed. (Although ran some additional precursory tests to see whether I could break anything else, but no breakage so far.)
-
Variable character_set_results can legally be NULL (for "no conversion.") This could result in a NULL deref that crashed the server. Fixed. (Although ran some additional precursory tests to see whether I could break anything else, but no breakage so far.)
-
- 03 Sep, 2006 1 commit
-
-
tsmith@maint1.mysql.com authored
into maint1.mysql.com:/data/localhome/tsmith/bk/mysql-5.0-maint
-
- 02 Sep, 2006 5 commits
-
-
msvensson@neptunus.(none) authored
into neptunus.(none):/home/msvensson/mysql/mysql-5.0
-
msvensson@neptunus.(none) authored
into neptunus.(none):/home/msvensson/mysql/mysql-5.0
-
grichter@bk-internal.mysql.com authored
into bk-internal.mysql.com:/data0/bk/mysql-5.0-cmake
-
tsmith@maint2.mysql.com authored
into maint2.mysql.com:/data/localhome/tsmith/bk/50
-
grichter@bk-internal.mysql.com authored
into bk-internal.mysql.com:/data0/bk/mysql-5.0-cmake
-
- 01 Sep, 2006 1 commit
-
-
cmiller@maint1.mysql.com authored
into maint1.mysql.com:/data/localhome/cmiller/mysql-5.0-maint
-