- 12 Apr, 2007 1 commit
-
-
jani@ua141d10.elisa.omakaista.fi authored
into ua141d10.elisa.omakaista.fi:/home/my/bk/mysql-5.0-marvel
-
- 10 Apr, 2007 2 commits
-
-
serg@janus.mylan authored
into janus.mylan:/usr/home/serg/Abk/mysql-5.0
-
serg@janus.mylan authored
a better fix, that works with 4.1 servers which don't send a fake Format_description_log_event.
-
- 09 Apr, 2007 2 commits
-
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/d2/hf/mrg/mysql-5.0-opt
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/d2/hf/mrg/mysql-5.0-opt
-
- 08 Apr, 2007 1 commit
-
-
kent@mysql.com/kent-amd64.(none) authored
into mysql.com:/home/kent/bk/tmp4/mysql-5.0-engines
-
- 07 Apr, 2007 4 commits
-
-
evgen@moonbone.local authored
into moonbone.local:/mnt/gentoo64/work/27586-bug-5.0-opt-mysql
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/d2/hf/mrg/mysql-5.0-opt
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/d2/hf/mrg/mysql-5.0-opt
-
holyfoot/hf@mysql.com/hfmain.(none) authored
into mysql.com:/d2/hf/mrg/mysql-4.1-opt
-
- 06 Apr, 2007 6 commits
-
-
evgen@moonbone.local authored
into moonbone.local:/mnt/gentoo64/work/27586-bug-5.0-opt-mysql
-
evgen@moonbone.local authored
NO_AUTO_VALUE_ON_ZERO mode. The table->auto_increment_field_not_null variable wasn't reset after reading a row which may lead to inserting a wrong value to the auto-increment field to the following row. The table->auto_increment_field_not_null variable is reset now right after a row is being written in the read_fixed_length() and the read_sep_field() functions. Removed wrong setting of the table->auto_increment_field_not_null variable in the read_sep_field() function.
-
tomas@whalegate.ndb.mysql.com authored
into whalegate.ndb.mysql.com:/home/tomas/mysql-5.0-ndb
-
into xiphis.org:/home/antony/work2/mysql-5.0-engines.merge
-
anozdrin/alik@ibm. authored
-
anozdrin/alik@ibm. authored
-
- 05 Apr, 2007 11 commits
-
-
tomas@whalegate.ndb.mysql.com authored
into whalegate.ndb.mysql.com:/home/tomas/mysql-5.0-ndb
-
tomas@whalegate.ndb.mysql.com authored
into whalegate.ndb.mysql.com:/home/tomas/mysql-5.0-ndb
-
mskold/marty@mysql.com/linux.site authored
into mysql.com:/windows/Linux_space/MySQL/mysql-5.0-ndb
-
tomas@whalegate.ndb.mysql.com authored
into whalegate.ndb.mysql.com:/home/tomas/mysql-5.0-ndb
-
tomas@whalegate.ndb.mysql.com authored
-
tomas@whalegate.ndb.mysql.com authored
- test case workaround to avoid random failures
-
mskold/marty@mysql.com/linux.site authored
into mysql.com:/windows/Linux_space/MySQL/mysql-5.0-ndb
-
mskold/marty@mysql.com/linux.site authored
into mysql.com:/windows/Linux_space/MySQL/mysql-5.0-ndb
-
mskold/marty@mysql.com/linux.site authored
-
mskold/marty@mysql.com/linux.site authored
-
into dev3-240.dev.cn.tlan:/home/justin.he/mysql/mysql-5.0/mysql-5.0-ndb-bj.merge
-
- 04 Apr, 2007 9 commits
-
-
tomas@whalegate.ndb.mysql.com authored
into whalegate.ndb.mysql.com:/home/tomas/mysql-5.0-ndb
-
mskold/marty@mysql.com/linux.site authored
In certain cases AFTER UPDATE/DELETE triggers on NDB tables that referenced subject table didn't see the results of operation which caused invocation of those triggers. In other words AFTER trigger invoked as result of update (or deletion) of particular row saw version of this row before update (or deletion). The problem occured because NDB handler in those cases postponed actual update/delete operations to be able to perform them later as one batch. This fix solves the problem by disabling this optimization for particular operation if subject table has AFTER trigger for this operation defined. To achieve this we introduce two new flags for handler::extra() method: HA_EXTRA_DELETE_CANNOT_BATCH and HA_EXTRA_UPDATE_CANNOT_BATCH. These are called if there exists AFTER DELETE/UPDATE triggers during a statement that potentially can generate calls to delete_row()/update_row(). This includes multi_delete/multi_update statements as well as insert statements that do delete/update as part of an ON DUPLICATE statement.
-
gkodinov/kgeorge@magare.gmz authored
into magare.gmz:/home/kgeorge/mysql/autopush/B27513-5.0-opt
-
gkodinov/kgeorge@magare.gmz authored
-
tsmith@quadxeon.mysql.com authored
into quadxeon.mysql.com:/benchmarks/ext3/TOSAVE/tsmith/bk/maint/mrg04/50
-
gkodinov/kgeorge@magare.gmz authored
into magare.gmz:/home/kgeorge/mysql/autopush/B27513-5.0-opt
-
igor@olga.mysql.com authored
into olga.mysql.com:/home/igor/mysql-5.0-opt
-
igor@olga.mysql.com authored
-
igor@olga.mysql.com authored
-
- 03 Apr, 2007 4 commits
-
-
igor@olga.mysql.com authored
into olga.mysql.com:/home/igor/mysql-5.0-opt
-
igor@olga.mysql.com authored
IN/BETWEEN predicates in sorting expressions. Wrong results may occur when the select list contains an expression with IN/BETWEEN predicate that differs from a sorting expression by an additional NOT only. Added the method Item_func_opt_neg::eq to compare correctly expressions containing [NOT] IN/BETWEEN. The eq method inherited from the Item_func returns TRUE when comparing 'a IN (1,2)' with 'a NOT IN (1,2)' that is not, of course, correct.
-
gkodinov/kgeorge@magare.gmz authored
crash bug doesn't reappear.
-
mskold/marty@mysql.com/linux.site authored
into mysql.com:/windows/Linux_space/MySQL/mysql-5.0-ndb
-