An error occurred fetching the project authors.
- 18 Nov, 2009 1 commit
-
-
Sven Sandberg authored
Problem: Some system functions that could return different values on master and slave were not marked unsafe. In particular: GET_LOCK IS_FREE_LOCK IS_USED_LOCK MASTER_POS_WAIT RELEASE_LOCK SLEEP SYSDATE VERSION Fix: Mark these functions unsafe.
-
- 24 Jun, 2009 1 commit
-
-
MySQL Build Team authored
> ------------------------------------------------------------ > revno: 2852.2.1 > revision-id: gni@mysql.com-20090403182157-de6ecrtzlgvpl5mk > parent: timothy.smith@sun.com-20090402083720-b7i3jr4dmvwjakcj > committer: Guangbao Ni <gni@mysql.com> > branch nick: bugteam-5.1-bug42640 > timestamp: Fri 2009-04-03 18:21:57 +0000 > message: > BUG#42640 mysqld crashes when unsafe statements are executed (STRICT_TRANS_TABLESmode) > > Mysql server crashes because unsafe statements warning is wrongly elevated to error, > which is set the error status of Diagnostics_area of the thread in THD::binlog_query(). > Yet the caller believes that binary logging shouldn't touch the status, so it will > set the status also later by my_ok(), my_error() or my_message() seperately > according to the execution result of the statement or transaction. > But the status of Diagnostics_area of the thread is allowed to set only once. > > Fixed to clear the error wrongly set by binary logging, but keep the warning message.
-
- 20 May, 2009 1 commit
-
-
He Zhenxing authored
-
- 03 Apr, 2009 1 commit
-
-
Guangbao Ni authored
Mysql server crashes because unsafe statements warning is wrongly elevated to error, which is set the error status of Diagnostics_area of the thread in THD::binlog_query(). Yet the caller believes that binary logging shouldn't touch the status, so it will set the status also later by my_ok(), my_error() or my_message() seperately according to the execution result of the statement or transaction. But the status of Diagnostics_area of the thread is allowed to set only once. Fixed to clear the error wrongly set by binary logging, but keep the warning message.
-
- 05 Mar, 2009 1 commit
-
-
Guangbao Ni authored
When binlog_format is STATEMENT and the statement is unsafe before, the unsafe warning/error message was issued without checking whether the SQL_LOG_BIN was turned on or not. Fixed with adding a sql_log_bin_toplevel flag in THD to check whether SQL_LOG_BIN is ON in current session whatever the current is in sp or not.
-
- 09 Feb, 2009 1 commit
-
-
Davi Arnaut authored
The problem is that a unfiltered user query was being passed as the format string parameter of sql_print_warning which later performs printf-like formatting, leading to crashes if the user query contains formatting instructions (ie: %s). Also, it was using THD::query as the source of the user query, but this variable is not meaningful in some situations -- in a delayed insert, it points to the table name. The solution is to pass the user query as a parameter for the format string and use the function parameter query_arg as the source of the user query.
-
- 26 Mar, 2008 1 commit
-
-
msvensson@pilot.mysql.com authored
-
- 18 Mar, 2008 1 commit
-
-
svoj@mysql.com/june.mysql.com authored
binlog_format=mixed Statement-based replication of DELETE ... LIMIT, UPDATE ... LIMIT, INSERT ... SELECT ... LIMIT is not safe as order of rows is not defined. With this fix, we issue a warning that this statement is not safe to replicate in statement mode, or go to row-based mode in mixed mode. Note that we may consider a statement as safe if ORDER BY primary_key is present. However it may confuse users to see very similiar statements replicated differently. Note 2: regular UPDATE statement (w/o LIMIT) is unsafe as well, but this patch doesn't address this issue. See comment from Kristian posted 18 Mar 10:55.
-
- 14 Mar, 2008 1 commit
-
-
mkindahl@dl145h.mysql.com authored
-
- 10 Mar, 2008 1 commit
-
-
sven@riska.(none) authored
safe. Fix: Move sql_mode: from the section of the test where safe variables are tested, to the section where unsafe variables are tested.
-
- 07 Mar, 2008 1 commit
-
-
sven@riska.(none) authored
Problem: in mixed and statement mode, a query that refers to a system variable will use the slave's value when replayed on slave. So if the value of a system variable is inserted into a table, the slave will differ from the master. Fix: mark statements that refer to a system variable as "unsafe", meaning they will be replicated by row in mixed mode and produce a warning in statement mode. There are some exceptions: some variables are actually replicated. Those should *not* be marked as unsafe. BUG#34732: mysqlbinlog does not print default values for auto_increment variables Problem: mysqlbinlog does not print default values for some variables, including auto_increment_increment and others. So if a client executing the output of mysqlbinlog has different default values, replication will be wrong. Fix: Always print default values for all variables that are replicated. I need to fix the two bugs at the same time, because the test cases would fail if I only fixed one of them.
-
- 05 Mar, 2008 1 commit
-
-
mkindahl@dl145h.mysql.com authored
-
- 03 Mar, 2008 1 commit
-
-
msvensson@pilot.mysql.com authored
Add missing drop view
-
- 11 Jan, 2008 1 commit
-
-
mkindahl@dl145h.mysql.com authored
-
- 19 Jun, 2007 1 commit
-
-
mats@kindahl-laptop.dnsalias.net authored
-
- 01 Jun, 2007 1 commit
-
-
mats@kindahl-laptop.dnsalias.net authored
-
- 14 May, 2007 1 commit
-
-
mats@romeo.kindahl.net authored
Replacing binlog_row_based_if_mixed with variable binlog_stmt_flags holding several flags and adding member functions to manipulate the flags. Added code to generate a warning when an attempt to log an unsafe statement to the binary log was made. The warning is both pushed to the SHOW WARNINGS table and written to the error log. The prevent flooding the error log, the warning is just written to the error log once per open session.
-