- 29 Jun, 2006 24 commits
-
-
ingo@mysql.com authored
into mysql.com:/home/mydev/mysql-5.0-bug11824
-
joerg@mysql.com authored
-
konstantin@mysql.com authored
into mysql.com:/opt/local/work/mysql-5.0-runtime
-
konstantin@mysql.com authored
into mysql.com:/opt/local/work/mysql-5.0-runtime
-
konstantin@mysql.com authored
into mysql.com:/opt/local/work/mysql-5.0-runtime
-
konstantin@mysql.com authored
-
lars@mysql.com authored
into mysql.com:/users/lthalmann/bk/MERGE/mysql-5.0-merge
-
ingo@mysql.com authored
-
stewart@mysql.com authored
into mysql.com:/home/stewart/Documents/MySQL/5.0/main
-
ingo@mysql.com authored
into mysql.com:/home/mydev/mysql-5.0-bug11824
-
konstantin@mysql.com authored
into mysql.com:/opt/local/work/mysql-5.0-runtime
-
jonas@perch.ndb.mysql.com authored
into perch.ndb.mysql.com:/home/jonas/src/mysql-5.0-release
-
tomas@poseidon.ndb.mysql.com authored
into poseidon.ndb.mysql.com:/home/tomas/mysql-5.0-main
-
tomas@poseidon.ndb.mysql.com authored
into poseidon.ndb.mysql.com:/home/tomas/mysql-5.0-main
-
tomas@poseidon.ndb.mysql.com authored
+ adopted signal to be as close as possible to 5.1...
-
kroki@mysql.com authored
-
jonas@perch.ndb.mysql.com authored
Fix compile error for forte
-
knielsen@mysql.com authored
into mysql.com:/data0/knielsen/tmp-5.0
-
knielsen@mysql.com authored
-
ingo@mysql.com authored
into mysql.com:/home/mydev/mysql-5.0-bug11824
-
ingo@mysql.com authored
into mysql.com:/home/mydev/mysql-5.0-bug11824
-
ingo@mysql.com authored
into mysql.com:/home/mydev/mysql-5.0-bug11824
-
ingo@mysql.com authored
into mysql.com:/home/mydev/mysql-5.0-bug11824
-
knielsen@mysql.com authored
-
- 28 Jun, 2006 16 commits
-
-
kroki@mysql.com authored
into mysql.com:/home/tomash/src/mysql_ab/mysql-5.0-bug10946
-
kroki@mysql.com authored
It was hard to distinguish case, when one was unable to create trigger on the table because trigger with same action time and event already existed for this table, from the case, when one tried to create trigger with name which was already occupied by some other trigger, since in both these cases we emitted ER_TRG_ALREADY_EXISTS error and message. Now we emit ER_NOT_SUPPORTED_YET error with appropriate additional message in the first case. There is no sense in introducing separate error for this situation since we plan to get rid of this limitation eventually.
-
konstantin@mysql.com authored
No test case as the bug is in an existing test case (rpl_trigger.test when it is run under valgrind). The warning was caused by memory corruption in replication slave: thd->db was pointing at a stack address that was previously used by sp_head::execute()::old_db. This happened because mysql_change_db behaved differently in replication slave and did not make a copy of the argument to assign to thd->db. The solution is to always free the old value of thd->db and allocate a new copy, regardless whether we're running in a replication slave or not.
-
jimw@mysql.com authored
into mysql.com:/home/jimw/my/mysql-5.0-16494
-
patg@govinda.patg.net authored
Pushbuild fixes to result file, test, and header file for federated.
-
jimw@mysql.com authored
-
jimw@mysql.com authored
into mysql.com:/home/jimw/my/mysql-5.0-18005
-
acurtis@xiphis.org authored
into xiphis.org:/home/antony/work2/mysql-5.0-engines.sync
-
patg@govinda.patg.net authored
into govinda.patg.net:/home/patg/mysql-build/mysql-5.0-engines-bug19773
-
acurtis@xiphis.org authored
into xiphis.org:/home/antony/work2/p4-bug12096.2-merge
-
lars@mysql.com authored
into mysql.com:/users/lthalmann/bk/MERGE/mysql-5.0-merge
-
ingo@mysql.com authored
A corrupt table with dynamic record format can crash the server when trying to select from it. I fixed the crash that resulted from the particular type of corruption that has been reported for this bug. No test case. To test it, one needs a table with a very special corruption. The bug report contains a file with such a table.
-
knielsen@mysql.com authored
In the Windows build files, the "Max nt" configuration for some reason had the mysql_client_test project disabled. Enable it.
-
lars@mysql.com authored
-
ingo@mysql.com authored
CHECK TABLE could complain about a fully intact spatial index. A wrong comparison operator was used for table checking. The result was that it checked for non-matching spatial keys. This succeeded if at least two different keys were present, but failed if only the matching key was present. I fixed the key comparison.
-
stewart@mysql.com authored
into mysql.com:/home/stewart/Documents/MySQL/5.0/merge
-