1. 14 Oct, 2009 1 commit
    • Sven Sandberg's avatar
      BUG#39934: Slave stops for engine that only support row-based logging · 73b296c4
      Sven Sandberg authored
      Post-push fix.
      Problem: After the original bugfix, if a statement is unsafe,
      binlog_format=mixed, and engine is statement-only, a warning was
      generated and the statement executed. However, it is a fundamental
      principle of binlogging that binlog_format=mixed should guarantee
      correct logging, no compromise. So correct behavior is to generate
      an error and don't execute the statement.
      Fix: Generate error instead of warning.
      Since issue_unsafe_warnings can only generate one error message,
      this allows us to simplify the code a bit too:
      decide_logging_format does not have to save the error code for
      issue_unsafe_warnings
      73b296c4
  2. 30 Sep, 2009 3 commits
  3. 04 Sep, 2009 1 commit
  4. 02 Sep, 2009 14 commits
  5. 01 Sep, 2009 6 commits
  6. 31 Aug, 2009 11 commits
  7. 30 Aug, 2009 3 commits
    • Staale Smedseng's avatar
      Merge from 5.1-bugteam · 7aa88fcb
      Staale Smedseng authored
      7aa88fcb
    • Alexey Kopytov's avatar
      Automerge. · 6070491d
      Alexey Kopytov authored
      6070491d
    • Alexey Kopytov's avatar
      Bug #46607: Assertion failed: (cond_type == Item::FUNC_ITEM) · 62b95b90
      Alexey Kopytov authored
                  results in server crash 
       
      check_group_min_max_predicates() assumed the input condition 
      item to be one of COND_ITEM, SUBSELECT_ITEM, or FUNC_ITEM. 
      Since a condition of the form "field" is also a valid condition 
      equivalent to "field <> 0", using such a condition in a query 
      where the loose index scan was chosen resulted in a debug 
      assertion failure. 
       
      Fixed by handling conditions of the FIELD_ITEM type in 
      check_group_min_max_predicates(). 
      62b95b90
  8. 29 Aug, 2009 1 commit
    • 's avatar
      Bug #44331 Restore of database with events produces warning in replication · 90e25c6f
      authored
      If an EVENT is created without the DEFINER clause set explicitly or with it set  
      to CURRENT_USER, the master and slaves become inconsistent. This issue stems from 
      the fact that in both cases, the DEFINER is set to the CURRENT_USER of the current 
      thread. On the master, the CURRENT_USER is the mysqld's user, while on the slave,  
      the CURRENT_USER is empty for the SQL Thread which is responsible for executing 
      the statement.
      
      To fix the problem, we do what follows. If the definer is not set explicitly,  
      a DEFINER clause is added when writing the query into binlog; if 'CURRENT_USER' is 
      used as the DEFINER, it is replaced with the value of the current user before 
      writing to binlog.
      90e25c6f