- 03 Oct, 2006 4 commits
-
-
kroki/tomash@moonlight.intranet authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-real-bug21726-fix
-
jani@ua141d10.elisa.omakaista.fi authored
wrong results in order by in some rare cases.
-
kroki/tomash@moonlight.intranet authored
invocations of LAST_INSERT_ID. Reding of LAST_INSERT_ID inside stored function wasn't noted by caller, and no LAST_INSERT_ID_EVENT was issued for binary log. The solution is to add THD::last_insert_id_used_bin_log, which is much like THD::last_insert_id_used, but is reset only for upper-level statements. This new variable is used to issue LAST_INSERT_ID_EVENT.
-
jani@ua141d10.elisa.omakaista.fi authored
into ua141d10.elisa.omakaista.fi:/home/my/bk/mysql-5.0
-
- 02 Oct, 2006 7 commits
-
-
-
kroki/tomash@moonlight.intranet authored
into moonlight.intranet:/home/tomash/src/mysql_ab/mysql-5.0-real-bug21726
-
kroki/tomash@moonlight.intranet authored
Non-upper-level INSERTs (the ones in the body of stored procedure, stored function, or trigger) into a table that have AUTO_INCREMENT column didn't affected the result of LAST_INSERT_ID() on this level. The problem was introduced with the fix of bug 6880, which in turn was introduced with the fix of bug 3117, where current insert_id value was remembered on the first call to LAST_INSERT_ID() (bug 3117) and was returned from that function until it was reset before the next _upper-level_ statement (bug 6880). The fix for bug#21726 brings back the behaviour of version 4.0, and implements the following: remember insert_id value at the beginning of the statement or expression (which at that point equals to the first insert_id value generated by the previous statement), and return that remembered value from LAST_INSERT_ID() or @@LAST_INSERT_ID. Thus, the value returned by LAST_INSERT_ID() is not affected by values generated by current statement, nor by LAST_INSERT_ID(expr) calls in this statement. Version 5.1 does not have this bug (it was fixed by WL 3146).
-
svoj@mysql.com/april.(none) authored
into mysql.com:/home/svoj/devel/mysql/merge/mysql-5.0-engines
-
svoj@mysql.com/april.(none) authored
into mysql.com:/home/svoj/devel/mysql/merge/mysql-5.0-engines
-
svoj@mysql.com/april.(none) authored
into mysql.com:/home/svoj/devel/mysql/merge/mysql-4.1-engines
-
svoj@mysql.com/april.(none) authored
into mysql.com:/home/svoj/devel/mysql/merge/mysql-4.1-engines
-
- 29 Sep, 2006 9 commits
-
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-4.0-bug20719
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-5.0-bug20627
-
svoj@mysql.com/april.(none) authored
into mysql.com:/home/svoj/devel/mysql/engines/mysql-5.0-engines
-
svoj@mysql.com/april.(none) authored
Was introduced with patch for bug#21675.
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-5.0-bug20627
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-4.1-bug22384
-
svoj@mysql.com/april.(none) authored
into mysql.com:/home/svoj/devel/mysql/engines/mysql-5.0-engines
-
svoj@mysql.com/april.(none) authored
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-5.0-bug22384
-
- 28 Sep, 2006 17 commits
-
-
evgen@moonbone.local authored
After merge fix
-
evgen@moonbone.local authored
into moonbone.local:/work/5505-bug-5.0-opt-mysql
-
evgen@moonbone.local authored
On an INSERT into an updatable but non-insertable view an error message was issued stating the view being not updatable. This can lead to a confusion of a user. A new error message is introduced. Is is showed when a user tries to insert into a non-insertable view.
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-5.0-bug22384
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-4.1-bug22384
-
svoj@mysql.com/april.(none) authored
into mysql.com:/home/svoj/devel/mysql/BUG21617/mysql-5.0-engines
-
svoj@mysql.com/april.(none) authored
into mysql.com:/home/svoj/devel/mysql/BUG21617/mysql-4.1-engines
-
svoj@mysql.com/april.(none) authored
Crash may happen when selecting from a merge table that has underlying tables with less indexes than in a merge table itself. If number of keys in merge table is not bigger than requested key number, return error.
-
svoj@mysql.com/april.(none) authored
into mysql.com:/home/svoj/devel/mysql/BUG21675/mysql-5.0-engines
-
svoj@mysql.com/april.(none) authored
into mysql.com:/home/svoj/devel/mysql/BUG21675/mysql-5.0-engines
-
svoj@mysql.com/april.(none) authored
If mysqld is linked against system installed zlib (which is likely compiled w/o LFS) and archive table exceedes 2G, mysqld will likely be terminated with SIGXFSZ. Prior to actual write perform a check if there is space in data file. This fixes abnormal process termination with SIGXFSZ. No test case for this bugfix.
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-4.1-bug20719-m
-
istruewing@chilla.local authored
Deletes on a big index could crash the index when it needs to shrink. Put a forgotten negation operator in. No test case. It is too big for the test suite. And it does not work with 4.0, only with higher versions. It is attached to the bug report.
-
gkodinov@dl145s.mysql.com authored
into dl145s.mysql.com:/data/bk/team_tree_merge/MERGE/mysql-5.0-opt
-
gkodinov@dl145s.mysql.com authored
into dl145s.mysql.com:/data/bk/team_tree_merge/MERGE/mysql-5.0-opt
-
gkodinov@dl145s.mysql.com authored
into dl145s.mysql.com:/data/bk/team_tree_merge/MERGE/mysql-4.1-opt
-
istruewing@chilla.local authored
into chilla.local:/home/mydev/mysql-5.0-bug20719-m
-
- 27 Sep, 2006 3 commits
-
-
gluh@mysql.com/gluh.(none) authored
-
gluh@mysql.com/gluh.(none) authored
-
svoj@mysql.com/april.(none) authored
-