- 28 Feb, 2007 4 commits
-
-
lars/lthalmann@dl145k.mysql.com authored
into mysql.com:/nfsdisk1/lars/MERGE/mysql-5.1-merge
-
gluh@mysql.com/eagle.(none) authored
-
gluh@eagle.(none) authored
into mysql.com:/home/gluh/MySQL/Merge/5.1-opt
-
gluh@mysql.com/eagle.(none) authored
-
- 27 Feb, 2007 15 commits
-
-
-
sergefp@pylon.mylan authored
into mysql.com:/home/psergey/mysql-5.1-bug26117
-
sergefp@mysql.com authored
Before the fix: ha_partition objects had ha_partition::m_part_info==NULL and that caused crash After: - The new ha_partition::clone() function makes the clones use parent's m_part_info value. - The parent ha_partition object remains responsible for deallocation of m_part_info.
-
lars/lthalmann@dl145k.mysql.com authored
into mysql.com:/nfsdisk1/lars/MERGE/mysql-5.1-merge
-
monty@mysql.com/narttu.mysql.fi authored
-
into mysql.com:/nfsdisk1/lars/MERGE/mysql-5.0-merge
-
lars/lthalmann@dl145h.mysql.com authored
into mysql.com:/nfsdisk1/lars/MERGE/mysql-5.1-merge
-
into mysql.com:/nfsdisk1/lars/MERGE/mysql-5.0-merge
-
monty@mysql.com/narttu.mysql.fi authored
-
cbell/Chuck@mysql_cab_desk. authored
SF/Triggers in SBR mode." BUG#14914 "SP: Uses of session variables in routines are not always replicated" BUG#25167 "Dupl. usage of user-variables in trigger/function is not replicated correctly" This patch corrects a minor error in the previous patch for BUG#20141. This patch corrects an errant code change to sp_head.cc. The comments for the first patch follow: User-defined variables used inside of stored functions/triggers in statements which did not update tables directly were not replicated. We also had problems with replication of user-defined variables which were used in triggers (or stored functions called from table-updating statements) more than once. This patch addresses the first issue by enabling logging of all references to user-defined variables in triggers/stored functions and not only references from table-updating statements. The second issue stemmed from the fact that for user-defined variables used from triggers or stored functions called from table-updating statements we were writing binlog events for each reference instead of only one event for the first reference. This problem is already solved for stored functions called from non-updating statements with help of "event unioning" mechanism. So the patch simply extends this mechanism to the case affected. It also fixes small problem in this mechanism which caused wrong logging of references to user-variables in cases when non-updating statement called several stored functions which used the same variable and some of these function calls were omitted from binlog as they were not updating any tables.
-
cbell/Chuck@mysql_cab_desk. authored
SF/Triggers in SBR mode." BUG#14914 "SP: Uses of session variables in routines are not always replicated" BUG#25167 "Dupl. usage of user-variables in trigger/function is not replicated correctly" This patch corrects a minor error in the previous patch for BUG#20141. This patch corrects an errant code change to sp_head.cc. The comments for the first patch follow: User-defined variables used inside of stored functions/triggers in statements which did not update tables directly were not replicated. We also had problems with replication of user-defined variables which were used in triggers (or stored functions called from table-updating statements) more than once. This patch addresses the first issue by enabling logging of all references to user-defined variables in triggers/stored functions and not only references from table-updating statements. The second issue stemmed from the fact that for user-defined variables used from triggers or stored functions called from table-updating statements we were writing binlog events for each reference instead of only one event for the first reference. This problem is already solved for stored functions called from non-updating statements with help of "event unioning" mechanism. So the patch simply extends this mechanism to the case affected. It also fixes small problem in this mechanism which caused wrong logging of references to user-variables in cases when non-updating statement called several stored functions which used the same variable and some of these function calls were omitted from binlog as they were not updating any tables.
-
-
gluh@eagle.(none) authored
into mysql.com:/home/gluh/MySQL/Merge/5.1-opt
-
gluh@mysql.com/eagle.(none) authored
-
gluh@mysql.com/eagle.(none) authored
-
- 26 Feb, 2007 18 commits
-
-
gbichot@dl145h.mysql.com authored
to the client only after the binlog write and engine commit. No testcase for this bug, as to reproduce it, we need to "kill -9" mysqld, which we cannot do in the testsuite. But, I tested by hand.
-
cbell/Chuck@mysql_cab_desk. authored
into mysql_cab_desk.:C:/source/C++/mysql-5.1-new-rpl
-
cbell/Chuck@mysql_cab_desk. authored
into mysql_cab_desk.:C:/source/c++/mysql-5.0-rpl
-
cbell/Chuck@mysql_cab_desk. authored
SF/Triggers in SBR mode." BUG#14914 "SP: Uses of session variables in routines are not always replicated" BUG#25167 "Dupl. usage of user-variables in trigger/function is not replicated correctly" User-defined variables used inside of stored functions/triggers in statements which did not update tables directly were not replicated. We also had problems with replication of user-defined variables which were used in triggers (or stored functions called from table-updating statements) more than once. This patch addresses the first issue by enabling logging of all references to user-defined variables in triggers/stored functions and not only references from table-updating statements. The second issue stemmed from the fact that for user-defined variables used from triggers or stored functions called from table-updating statements we were writing binlog events for each reference instead of only one event for the first reference. This problem is already solved for stored functions called from non-updating statements with help of "event unioning" mechanism. So the patch simply extends this mechanism to the case affected. It also fixes small problem in this mechanism which caused wrong logging of references to user-variables in cases when non-updating statement called several stored functions which used the same variable and some of these function calls were omitted from binlog as they were not updating any tables.
-
mats@romeo.(none) authored
-
mats@romeo.(none) authored
Adding code to release allocated memory when tables_to_lock list is cleared.
-
gluh@mysql.com/eagle.(none) authored
-
gluh@eagle.(none) authored
into mysql.com:/home/gluh/MySQL/Merge/5.1-opt
-
gluh@eagle.(none) authored
into mysql.com:/home/gluh/MySQL/Merge/5.1-opt
-
gluh@mysql.com/eagle.(none) authored
into mysql.com:/home/gluh/MySQL/Merge/5.0-opt
-
gluh@mysql.com/eagle.(none) authored
-
gluh@eagle.(none) authored
into mysql.com:/home/gluh/MySQL/Merge/5.1-opt
-
mats@romeo.(none) authored
into romeo.(none):/home/bk/b25091-mysql-5.1-new-rpl
-
mats@romeo.(none) authored
into romeo.(none):/home/bk/b25091-mysql-5.1-new-rpl
-
mats@romeo.(none) authored
With this patch, statements that change metadata (in the mysql database) is logged as statements, while normal changes (e.g., using INSERT, DELETE, and/or UPDATE) is logged according to the format in effect. The log tables (i.e., general_log and slow_log) are not replicated at all. With this patch, the following statements are replicated as statements: GRANT, REVOKE (ALL), CREATE USER, DROP USER, and RENAME USER.
-
knielsen@ymer.(none) authored
into ymer.(none):/tmp/mysql-5.1
-
knielsen@ymer.(none) authored
-
evgen@sunlight.local authored
Post fix for bug#23800.
-
- 25 Feb, 2007 1 commit
-
-
evgen@sunlight.local authored
Post fix for bug#23800. Copy the table name of an Item_outer_ref to the conventional memory.
-
- 24 Feb, 2007 2 commits
-
-
lars/lthalmann@dl145k.mysql.com authored
into mysql.com:/nfsdisk1/lars/MERGE/mysql-5.1-merge
-
-