An error occurred fetching the project authors.
  1. 11 Nov, 2010 1 commit
    • Dmitry Lenev's avatar
      Patch that refactors global read lock implementation and fixes · 378cdc58
      Dmitry Lenev authored
      bug #57006 "Deadlock between HANDLER and FLUSH TABLES WITH READ
      LOCK" and bug #54673 "It takes too long to get readlock for
      'FLUSH TABLES WITH READ LOCK'".
      
      The first bug manifested itself as a deadlock which occurred
      when a connection, which had some table open through HANDLER
      statement, tried to update some data through DML statement
      while another connection tried to execute FLUSH TABLES WITH
      READ LOCK concurrently.
      
      What happened was that FTWRL in the second connection managed
      to perform first step of GRL acquisition and thus blocked all
      upcoming DML. After that it started to wait for table open
      through HANDLER statement to be flushed. When the first connection
      tried to execute DML it has started to wait for GRL/the second
      connection creating deadlock.
      
      The second bug manifested itself as starvation of FLUSH TABLES
      WITH READ LOCK statements in cases when there was a constant
      stream of concurrent DML statements (in two or more
      connections).
      
      This has happened because requests for protection against GRL
      which were acquired by DML statements were ignoring presence of
      pending GRL and thus the latter was starved.
      
      This patch solves both these problems by re-implementing GRL
      using metadata locks.
      
      Similar to the old implementation acquisition of GRL in new
      implementation is two-step. During the first step we block
      all concurrent DML and DDL statements by acquiring global S
      metadata lock (each DML and DDL statement acquires global IX
      lock for its duration). During the second step we block commits
      by acquiring global S lock in COMMIT namespace (commit code
      acquires global IX lock in this namespace).
      
      Note that unlike in old implementation acquisition of
      protection against GRL in DML and DDL is semi-automatic.
      We assume that any statement which should be blocked by GRL
      will either open and acquires write-lock on tables or acquires
      metadata locks on objects it is going to modify. For any such
      statement global IX metadata lock is automatically acquired
      for its duration.
      
      The first problem is solved because waits for GRL become
      visible to deadlock detector in metadata locking subsystem
      and thus deadlocks like one in the first bug become impossible.
      
      The second problem is solved because global S locks which
      are used for GRL implementation are given preference over
      IX locks which are acquired by concurrent DML (and we can
      switch to fair scheduling in future if needed).
      
      Important change:
      FTWRL/GRL no longer blocks DML and DDL on temporary tables.
      Before this patch behavior was not consistent in this respect:
      in some cases DML/DDL statements on temporary tables were
      blocked while in others they were not. Since the main use cases
      for FTWRL are various forms of backups and temporary tables are
      not preserved during backups we have opted for consistently
      allowing DML/DDL on temporary tables during FTWRL/GRL.
      
      Important change:
      This patch changes thread state names which are used when
      DML/DDL of FTWRL is waiting for global read lock. It is now
      either "Waiting for global read lock" or "Waiting for commit
      lock" depending on the stage on which FTWRL is.
      
      Incompatible change:
      To solve deadlock in events code which was exposed by this
      patch we have to replace LOCK_event_metadata mutex with
      metadata locks on events. As result we have to prohibit
      DDL on events under LOCK TABLES.
      
      This patch also adds extensive test coverage for interaction
      of DML/DDL and FTWRL.
      
      Performance of new and old global read lock implementations
      in sysbench tests were compared. There were no significant
      difference between new and old implementations.
      378cdc58
  2. 26 Aug, 2010 1 commit
    • Jon Olav Hauglid's avatar
      Bug #44171 KILL ALTER EVENT can crash the server · bbd7277f
      Jon Olav Hauglid authored
      This assert could be triggered if ALTER EVENT failed to load the
      event after altering it. Failing to load the event could for 
      example happen because of KILL QUERY.
      
      The assert tested that the result of a failed load_named_event()
      was OP_LOAD_ERROR. However since load_named_event() returns bool,
      this assert did not make any sense. This patch therefore removes
      the assert, fixing the problem. The patch also removes 
      enum_events_error_code since it was unused.
      
      No test case added. The bug fix is trivial and this bug was
      easily detected by RQG tests. Further, adding a MTR test case
      for this bug would require adding sync points to make the
      test case repeatable.
      bbd7277f
  3. 13 Aug, 2010 1 commit
    • Jon Olav Hauglid's avatar
      Bug #54105 assert in MDL_context::release_locks_stored_before · 3bc4d540
      Jon Olav Hauglid authored
      The problem was that SHOW CREATE EVENT released all metadata locks
      held by the current transaction. This made any exisiting savepoints
      invalid, triggering the assert when ROLLBACK TO SAVEPOINT later
      was executed.
      
      This patch fixes the problem by making sure SHOW CREATE EVENT only
      releases metadata locks acquired by the statement itself.
      
      Test case added to event_trans.test.
      3bc4d540
  4. 27 Jul, 2010 1 commit
    • Konstantin Osipov's avatar
      A pre-requisite patch for the fix for Bug#52044. · ec2c3bf2
      Konstantin Osipov authored
      This patch also fixes Bug#55452 "SET PASSWORD is
      replicated twice in RBR mode".
      
      The goal of this patch is to remove the release of 
      metadata locks from close_thread_tables().
      This is necessary to not mistakenly release
      the locks in the course of a multi-step
      operation that involves multiple close_thread_tables()
      or close_tables_for_reopen().
      
      On the same token, move statement commit outside 
      close_thread_tables().
      
      Other cleanups:
      Cleanup COM_FIELD_LIST.
      Don't call close_thread_tables() in COM_SHUTDOWN -- there
      are no open tables there that can be closed (we leave
      the locked tables mode in THD destructor, and this
      close_thread_tables() won't leave it anyway).
      
      Make open_and_lock_tables() and open_and_lock_tables_derived()
      call close_thread_tables() upon failure.
      Remove the calls to close_thread_tables() that are now
      unnecessary.
      
      Simplify the back off condition in Open_table_context.
      
      Streamline metadata lock handling in LOCK TABLES 
      implementation.
      
      Add asserts to ensure correct life cycle of 
      statement transaction in a session.
      
      Remove a piece of dead code that has also become redundant
      after the fix for Bug 37521.
      ec2c3bf2
  5. 31 Mar, 2010 1 commit
    • Mats Kindahl's avatar
      WL#5030: Split and remove mysql_priv.h · e409d6f6
      Mats Kindahl authored
      This patch:
      
      - Moves all definitions from the mysql_priv.h file into
        header files for the component where the variable is
        defined
      - Creates header files if the component lacks one
      - Eliminates all include directives from mysql_priv.h
      - Eliminates all circular include cycles
      - Rename time.cc to sql_time.cc
      - Rename mysql_priv.h to sql_priv.h
      e409d6f6
  6. 28 Mar, 2010 1 commit
    • 's avatar
      Bug #50095 Multi statement including CREATE EVENT causes rotten binlog entry · 8d22c5f3
      authored
      The log event of 'CREATE EVENT' was being binlogged with garbage
      at the end of the query if 'CREATE EVENT' is followed by another SQL statement
      and they were executed as one command.
      for example:
          DELIMITER |;
          CREATE EVENT e1 ON EVERY DAY DO SELECT 1; SELECT 'a';
          DELIMITER ;|
      When binlogging 'CREATE EVENT', we always create a new statement with definer
      and write it into the log event. The new statement is made from cpp_buf(preprocessed buffer).
      which is not a c string(end with '\0'), but it is copied as a c string.
      
      In this patch, cpp_buf is copied with its length.
      8d22c5f3
  7. 15 Mar, 2010 1 commit
    • Jon Olav Hauglid's avatar
      Bug #51160 Deadlock around SET GLOBAL EVENT_SCHEDULER = ON|OFF · dd69b281
      Jon Olav Hauglid authored
      This deadlock could occour betweeen one connection executing
      SET GLOBAL EVENT_SCHEDULER= ON and another executing SET GLOBAL
      EVENT_SCHEDULER= OFF. The bug was introduced by WL#4738.
      
      The first connection would hold LOCK_event_metadata (protecting
      the global variable) while trying to lock LOCK_global_system_variables
      starting the event scheduler thread (in THD:init()).
      
      The second connection would hold LOCK_global_system_variables
      while trying to get LOCK_event_scheduler after stopping the event
      scheduler inside event_scheduler_update().
      
      This patch fixes the problem by not using LOCK_event_metadata to
      protect the event_scheduler variable. It is still protected using
      LOCK_global_system_variables. This fixes the deadlock as it removes 
      one of the two mutexes used to produce it.
      
      However, this patch opens up the possibility that the event_scheduler
      variable and the real event_scheduler state can become out of sync
      (e.g. variable = OFF, but scheduler running). But this can only
      happen under very unlikely conditions - two concurrent SET GLOBAL
      statments, with one thread interrupted at the exact wrong moment.
      This is preferable to having the possibility of a deadlock.
      
      This patch also fixes a bug where it was possible to exit create_event()
      without releasing LOCK_event_metadata if running out of memory during
      its exection.
      
      No test case added since a repeatable test case would have required
      excessive use of new sync points. Instead we rely on the fact that
      this bug was easily reproduceable using RGQ tests.
      dd69b281
  8. 10 Feb, 2010 1 commit
  9. 09 Feb, 2010 1 commit
    • Luis Soares's avatar
      BUG#51021: current_stmt_binlog_row_based not removed in next-mr · 9ba55830
      Luis Soares authored
      As part of BUG@39934 fix, the public:
       - THD::current_stmt_binlog_row_based 
      variable had been removed and replaced by a private variable:
       - THD::current_stmt_binlog_format. 
      
      THD was refactored and some modifiers and accessors were
      implemented for the new variable.
      
      However, due to a bad merge, the
      THD::current_stmt_binlog_row_based variable is back as a public
      member of THD. This in itself is already potentially
      harmful. What's even worse is that while merging some more
      patches and resolving conflicts, the variable started being used
      again, which is obviously wrong.
      
      To fix this we:
        1. remove the extraneous variable from sql_class.h
        2. revert a bad merge for BUG#49132
        3. merge BUG#49132 properly again (actually, making use of the
           cset used to merge the original patch to mysql-pe).
      9ba55830
  10. 04 Feb, 2010 1 commit
    • Konstantin Osipov's avatar
      Merge next-mr -> next-4284. · 06e1a73a
      Konstantin Osipov authored
      Cherry-pick a fix Bug#37148 from next-mr, to preserve
      file ids of the added files, and ensure that all the necessary
      changes have been pulled.
      
      Since initially Bug#37148 was null-merged into 6.0,
      the changeset that is now being cherry-picked was likewise
      null merged into next-4284.
      
      Now that Bug#37148 has been reapplied to 6.0, try to make
      it work with next-4284. This is also necessary to be able
      to pull other changes from 5.1-rep into next-4284.
      
      To resolve the merge issues use this changeset applied
      to 6.0:
      revid:jperkin@sun.com-20091216103628-ylhqf7s6yegui2t9
      revno: 3776.1.1
      committer: He Zhenxing <zhenxing.he@sun.com>
      branch nick: 6.0-codebase-bugfixing
      timestamp: Thu 2009-12-17 17:02:50 +0800
      message:
        Fix merge problem with Bug#37148
      
      
      06e1a73a
  11. 02 Feb, 2010 1 commit
    • Alexander Nozdrin's avatar
      Revert a patch for Bug#48231, which introduced valgrind warnings. · f392edda
      Alexander Nozdrin authored
      Original revision:
      ------------------------------------------------------------
      revision-id: li-bing.song@sun.com-20100130124925-o6sfex42b6noyc6x
      parent: joro@sun.com-20100129145427-0n79l9hnk0q43ajk
      committer: <Li-Bing.Song@sun.com>
      branch nick: mysql-5.1-bugteam
      timestamp: Sat 2010-01-30 20:49:25 +0800
      message:
        Bug #48321  CURRENT_USER() incorrectly replicated for DROP/RENAME USER;
                    REVOKE/GRANT; ALTER EVENT.
        
        The following statements support the CURRENT_USER() where a user is needed.
          DROP USER 
          RENAME USER CURRENT_USER() ...
          GRANT ... TO CURRENT_USER()
          REVOKE ... FROM CURRENT_USER()
          ALTER DEFINER = CURRENT_USER() EVENT
        but, When these statements are binlogged, CURRENT_USER() just is binlogged
        as 'CURRENT_USER()', it is not expanded to the real user name. When slave 
        executes the log event, 'CURRENT_USER()' is expand to the user of slave 
        SQL thread, but SQL thread's user name always NULL. This breaks the replication.
        
        After this patch, All above statements are rewritten when they are binlogged.
        The CURRENT_USER() is expanded to the real user's name and host.
      ------------------------------------------------------------
      f392edda
  12. 30 Jan, 2010 1 commit
    • 's avatar
      Bug #48321 CURRENT_USER() incorrectly replicated for DROP/RENAME USER; · 788c28ac
      authored
                  REVOKE/GRANT; ALTER EVENT.
      
      The following statements support the CURRENT_USER() where a user is needed.
        DROP USER 
        RENAME USER CURRENT_USER() ...
        GRANT ... TO CURRENT_USER()
        REVOKE ... FROM CURRENT_USER()
        ALTER DEFINER = CURRENT_USER() EVENT
      but, When these statements are binlogged, CURRENT_USER() just is binlogged
      as 'CURRENT_USER()', it is not expanded to the real user name. When slave 
      executes the log event, 'CURRENT_USER()' is expand to the user of slave 
      SQL thread, but SQL thread's user name always NULL. This breaks the replication.
      
      After this patch, All above statements are rewritten when they are binlogged.
      The CURRENT_USER() is expanded to the real user's name and host.
      788c28ac
  13. 24 Jan, 2010 1 commit
  14. 22 Jan, 2010 2 commits
  15. 21 Jan, 2010 1 commit
    • Dmitry Lenev's avatar
      Patch that changes metadata locking subsystem to use mutex per lock and · a63f8480
      Dmitry Lenev authored
      condition variable per context instead of one mutex and one conditional
      variable for the whole subsystem.
      
      This should increase concurrency in this subsystem.
      
      It also opens the way for further changes which are necessary to solve
      such bugs as bug #46272 "MySQL 5.4.4, new MDL: unnecessary deadlock"
      and bug #37346 "innodb does not detect deadlock between update and alter
      table".
      
      Two other notable changes done by this patch:
      
      - MDL subsystem no longer implicitly acquires global intention exclusive
        metadata lock when per-object metadata lock is acquired. Now this has
        to be done by explicit calls outside of MDL subsystem.
      - Instead of using separate MDL_context for opening system tables/tables
        for purposes of I_S we now create MDL savepoint in the main context
        before opening tables and rollback to this savepoint after closing
        them. This means that it is now possible to get ER_LOCK_DEADLOCK error
        even not inside a transaction. This might happen in unlikely case when
        one runs DDL on one of system tables while also running DDL on some
        other tables. Cases when this ER_LOCK_DEADLOCK error is not justified
        will be addressed by advanced deadlock detector for MDL subsystem which
        we plan to implement.
      a63f8480
  16. 19 Jan, 2010 1 commit
  17. 07 Jan, 2010 1 commit
  18. 22 Dec, 2009 1 commit
    • Sergei Golubchik's avatar
      WL#4738 streamline/simplify @@variable creation process · ae2768ce
      Sergei Golubchik authored
      Bug#16565 mysqld --help --verbose does not order variablesBug#20413 sql_slave_skip_counter is not shown in show variables
      Bug#20415 Output of mysqld --help --verbose is incomplete
      Bug#25430 variable not found in SELECT @@global.ft_max_word_len;
      Bug#32902 plugin variables don't know their names
      Bug#34599 MySQLD Option and Variable Reference need to be consistent in formatting!
      Bug#34829 No default value for variable and setting default does not raise error
      Bug#34834 ? Is accepted as a valid sql mode
      Bug#34878 Few variables have default value according to documentation but error occurs  
      Bug#34883 ft_boolean_syntax cant be assigned from user variable to global var.
      Bug#37187 `INFORMATION_SCHEMA`.`GLOBAL_VARIABLES`: inconsistent status
      Bug#40988 log_output_basic.test succeeded though syntactically false.
      Bug#41010 enum-style command-line options are not honoured (maria.maria-recover fails)
      Bug#42103 Setting key_buffer_size to a negative value may lead to very large allocations 
      Bug#44691 Some plugins configured as MYSQL_PLUGIN_MANDATORY in can be disabled
      Bug#44797 plugins w/o command-line options have no disabling option in --help
      Bug#46314 string system variables don't support expressions
      Bug#46470 sys_vars.max_binlog_cache_size_basic_32 is broken
      Bug#46586 When using the plugin interface the type "set" for options caused a crash.
      Bug#47212 Crash in DBUG_PRINT in mysqltest.cc when trying to print octal number
      Bug#48758 mysqltest crashes on sys_vars.collation_server_basic in gcov builds
      Bug#49417 some complaints about mysqld --help --verbose output
      Bug#49540 DEFAULT value of binlog_format isn't the default value
      Bug#49640 ambiguous option '--skip-skip-myisam' (double skip prefix)
      Bug#49644 init_connect and \0
      Bug#49645 init_slave and multi-byte characters
      Bug#49646 mysql --show-warnings crashes when server dies
      ae2768ce
  19. 03 Dec, 2009 1 commit
    • Konstantin Osipov's avatar
      Backport of: · 4ae05129
      Konstantin Osipov authored
      ------------------------------------------------------------
      revno: 2630.13.16
      committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
      branch nick: WL#4284
      timestamp: Sat 2008-07-26 13:38:20 -0300
      message:
      WL#4284: Transactional DDL locking
      
      SQL statements' effect on transactions.
      
      Currently the MySQL server and its storage engines are not
      capable of rolling back operations that define or modify data
      structures (also known as DDL statements) or operations that
      alter any of the system tables (the mysql database). Allowing
      these group of statements to participate in transactions
      is unfeasible at this time (since rollback has no effect
      whatsoever on them) and goes against the design of our metadata
      locking subsystem.
      
      The solution is to issue implicit commits before and after
      those statements execution. This effectively confines each of
      those statements to its own special transaction and ensures
      that metadata locks taken during this special transaction
      are not leaked into posterior statements/transactions.
      4ae05129
  20. 21 Nov, 2009 1 commit
    • He Zhenxing's avatar
      BUG#37148 Most callers of mysql_bin_log.write ignore the return result · 9b65f578
      He Zhenxing authored
      This is the non-ndb part of the patch.
      
      The return value of mysql_bin_log.write was ignored by most callers,
      which may lead to inconsistent on master and slave if the transaction
      was committed while the binlog was not correctly written. If
      my_error() is call in mysql_bin_log.write, this could also lead to
      assertion issue if my_ok() or my_error() is called after.
      
      This fixed the problem by let the caller to check and handle the
      return value of mysql_bin_log.write. This patch only adresses the
      simple cases.
      9b65f578
  21. 19 Nov, 2009 1 commit
    • Mattias Jonsson's avatar
      Bug#32115: Bad use of Name_resolution_context from current LEX in partitioning · 92bfebb6
      Mattias Jonsson authored
      port from mysql-next (5.4) to mysql-next-mr-bugfixing (5.5/5.6?)
      
      2755 Konstantin Osipov	2008-11-27
      Bug#32115 will remove the pre-requisite to initialize LEX to open tables.
      This dependency was added in 5.1 and was supposed to be removed in 6.0.
      Remove asserts and initialization of LEX in places where we don't deal
      with partitioned tables.
      92bfebb6
  22. 21 Oct, 2009 1 commit
    • Konstantin Osipov's avatar
      Backport of revno 2630.28.10, 2630.28.31, 2630.28.26, 2630.33.1, · d4632dff
      Konstantin Osipov authored
      2630.39.1, 2630.28.29, 2630.34.3, 2630.34.2, 2630.34.1, 2630.29.29,
      2630.29.28, 2630.31.1, 2630.28.13, 2630.28.10, 2617.23.14 and
      some other minor revisions.
      
      This patch implements: 
      
      WL#4264 "Backup: Stabilize Service Interface" -- all the
      server prerequisites except si_objects.{h,cc} themselves (they can
      be just copied over, when needed).
      
      WL#4435: Support OUT-parameters in prepared statements.
      
      (and all issues in the initial patches for these two
      tasks, that were discovered in pushbuild and during testing).
      
      Bug#39519: mysql_stmt_close() should flush all data
      associated with the statement.
      
      After execution of a prepared statement, send OUT parameters of the invoked
      stored procedure, if any, to the client.
      
      When using the binary protocol, send the parameters in an additional result
      set over the wire.  When using the text protocol, assign out parameters to
      the user variables from the CALL(@var1, @var2, ...) specification.
      
      The following refactoring has been made:
        - Protocol::send_fields() was renamed to Protocol::send_result_set_metadata();
        - A new Protocol::send_result_set_row() was introduced to incapsulate
          common functionality for sending row data.
        - Signature of Protocol::prepare_for_send() was changed: this operation
          does not need a list of items, the number of items is fully sufficient.
      
      The following backward incompatible changes have been made:
        - CLIENT_MULTI_RESULTS is now enabled by default in the client;
        - CLIENT_PS_MULTI_RESUTLS is now enabled by default in the client.
      d4632dff
  23. 16 Oct, 2009 1 commit
    • Georgi Kodinov's avatar
      Bug #40877: multi statement execution fails in 5.1.30 · 8f6f3dba
      Georgi Kodinov authored
            
      Implemented the server infrastructure for the fix:
      
      1. Added a function LEX_STRING *thd_query_string(THD) to return
      a LEX_STRING structure instead of char *.
      This is the function that must be called in innodb instead of 
      thd_query()
      
      2. Did some encapsulation in THD : aggregated thd_query and 
      thd_query_length into a LEX_STRING and made accessor and mutator 
      methods for easy code updating. 
      
      3. Updated the server code to use the new methods where applicable.
      8f6f3dba
  24. 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
  25. 24 Jul, 2009 1 commit
  26. 14 Jul, 2009 1 commit
    • Sven Sandberg's avatar
      BUG#39934: Slave stops for engine that only support row-based logging · f3985c64
      Sven Sandberg authored
      General overview:
      The logic for switching to row format when binlog_format=MIXED had
      numerous flaws. The underlying problem was the lack of a consistent
      architecture.
      General purpose of this changeset:
      This changeset introduces an architecture for switching to row format
      when binlog_format=MIXED. It enforces the architecture where it has
      to. It leaves some bugs to be fixed later. It adds extensive tests to
      verify that unsafe statements work as expected and that appropriate
      errors are produced by problems with the selection of binlog format.
      It was not practical to split this into smaller pieces of work.
      
      Problem 1:
      To determine the logging mode, the code has to take several parameters
      into account (namely: (1) the value of binlog_format; (2) the
      capabilities of the engines; (3) the type of the current statement:
      normal, unsafe, or row injection). These parameters may conflict in
      several ways, namely:
       - binlog_format=STATEMENT for a row injection
       - binlog_format=STATEMENT for an unsafe statement
       - binlog_format=STATEMENT for an engine only supporting row logging
       - binlog_format=ROW for an engine only supporting statement logging
       - statement is unsafe and engine does not support row logging
       - row injection in a table that does not support statement logging
       - statement modifies one table that does not support row logging and
         one that does not support statement logging
      Several of these conflicts were not detected, or were detected with
      an inappropriate error message. The problem of BUG#39934 was that no
      appropriate error message was written for the case when an engine
      only supporting row logging executed a row injection with
      binlog_format=ROW. However, all above cases must be handled.
      Fix 1:
      Introduce new error codes (sql/share/errmsg.txt). Ensure that all
      conditions are detected and handled in decide_logging_format()
      
      Problem 2:
      The binlog format shall be determined once per statement, in
      decide_logging_format(). It shall not be changed before or after that.
      Before decide_logging_format() is called, all information necessary to
      determine the logging format must be available. This principle ensures
      that all unsafe statements are handled in a consistent way.
      However, this principle is not followed:
      thd->set_current_stmt_binlog_row_based_if_mixed() is called in several
      places, including from code executing UPDATE..LIMIT,
      INSERT..SELECT..LIMIT, DELETE..LIMIT, INSERT DELAYED, and
      SET @@binlog_format. After Problem 1 was fixed, that caused
      inconsistencies where these unsafe statements would not print the
      appropriate warnings or errors for some of the conflicts.
      Fix 2:
      Remove calls to THD::set_current_stmt_binlog_row_based_if_mixed() from
      code executed after decide_logging_format(). Compensate by calling the
      set_current_stmt_unsafe() at parse time. This way, all unsafe statements
      are detected by decide_logging_format().
      
      Problem 3:
      INSERT DELAYED is not unsafe: it is logged in statement format even if
      binlog_format=MIXED, and no warning is printed even if
      binlog_format=STATEMENT. This is BUG#45825.
      Fix 3:
      Made INSERT DELAYED set itself to unsafe at parse time. This allows
      decide_logging_format() to detect that a warning should be printed or
      the binlog_format changed.
      
      Problem 4:
      LIMIT clause were not marked as unsafe when executed inside stored
      functions/triggers/views/prepared statements. This is
      BUG#45785.
      Fix 4:
      Make statements containing the LIMIT clause marked as unsafe at
      parse time, instead of at execution time. This allows propagating
      unsafe-ness to the view.
      f3985c64
  27. 09 Apr, 2009 1 commit
    • He Zhenxing's avatar
      Post fix of BUG#37145 · 41361d89
      He Zhenxing authored
      Binlog the CREATE EVENT unless the created event been successfully dropped
      
      Modified Query_log_event constructor to make sure that error_code
      is not set to ER_SERVER_SHUTDOWN or ER_QUERY_INTERRUPTED errors
      when NOT_KILLED
      41361d89
  28. 09 May, 2008 1 commit
  29. 22 Feb, 2008 1 commit
  30. 19 Feb, 2008 1 commit
  31. 30 Nov, 2007 1 commit
  32. 05 Nov, 2007 1 commit
    • istruewing@stella.local's avatar
      Bug#31210 - INSERT DELAYED crashes server when used on · 3eaf82a1
      istruewing@stella.local authored
                  partitioned table
      
      Trying INSERT DELAYED on a partitioned table, that has not been
      used right before, crashes the server. When a table is used for
      select or update, it is kept open for some time. This period I
      mean with "right before".
      
      Information about partitioning of a table is stored in form of
      a string in the .frm file. Parsing of this string requires a
      correctly set up lexical analyzer (lex). The partitioning code
      uses a new temporary instance of a lex. But it does still refer
      to the previously active lex. The delayd insert thread does not
      initialize its lex though...
      
      Added initialization for thd->lex before open table in the delayed
      thread and at all other places where it is necessary to call
      lex_start() if all tables would be partitioned and need to parse
      the .frm file.
      3eaf82a1
  33. 22 Oct, 2007 1 commit
  34. 19 Oct, 2007 1 commit
    • anozdrin/alik@station.'s avatar
      Patch for BUG#31111: --read-only crashes MySQL (events fail to load). · c60397ef
      anozdrin/alik@station. authored
      There actually were several problems here:
        - WRITE-lock is required to load events from the mysql.event table,
          but in the read-only mode an ordinary user can not acquire it;
        - Security_context::master_access attribute was not properly
          initialized in Security_context::init(), which led to differences
          in behavior with and without debug configure options.
        - if the server failed to load events from mysql.event, it forgot to
          close the mysql.event table, that led to the coredump, described
          in the bug report.
      
      The patch is to fix all these problems:
        - Use the super-user to acquire WRITE-lock on the mysql.even table;
        - The WRITE-lock is acquired by the event scheduler in two cases:
          - on initial loading of events from the database;
          - when an event has been executed, so its attributes should
            be updated.
          Other cases when WRITE-lock is needed for the mysql.event table
          happen under the user account. So, nothing should be changed there
          for the read-only mode. The user is able to create/update/drop
          an event only if he is a super-user.
        - Initialize Security_context::master_access;
        - Close the mysql.event table in case something went wrong.
      c60397ef
  35. 15 Aug, 2007 2 commits
  36. 12 Jul, 2007 1 commit
    • anozdrin/alik@ibm.'s avatar
      Fix for 5.1 for BUG#10491: Server returns data as charset binary · 3f2e94c4
      anozdrin/alik@ibm. authored
      SHOW CREATE TABLE or SELECT FROM I_S.
      
      This is the last patch for this bug, which depends on the big
      CS patch and was pending.
      
      The problem was that SHOW CREATE statements returned original
      queries in the binary character set. That could cause the query
      to be unreadable.
      
      The fix is to use original character_set_client when sending
      the original query to the client. In order to preserve the query
      in mysqldump, 'binary' character set results should be set when
      issuing SHOW CREATE statement. If either source or destination
      character set is 'binary' , no conversion is performed.
      The idea is that since the source character set is no longer
      'binary', we fix the destination character set to still produce
      valid dumps.
      3f2e94c4
  37. 28 Jun, 2007 1 commit
    • anozdrin/alik@ibm.'s avatar
      Patch for the following bugs: · 9fae9ef6
      anozdrin/alik@ibm. authored
        - BUG#11986: Stored routines and triggers can fail if the code
          has a non-ascii symbol
        - BUG#16291: mysqldump corrupts string-constants with non-ascii-chars
        - BUG#19443: INFORMATION_SCHEMA does not support charsets properly
        - BUG#21249: Character set of SP-var can be ignored
        - BUG#25212: Character set of string constant is ignored (stored routines)
        - BUG#25221: Character set of string constant is ignored (triggers)
      
      There were a few general problems that caused these bugs:
      1. Character set information of the original (definition) query for views,
         triggers, stored routines and events was lost.
      2. mysqldump output query in client character set, which can be
         inappropriate to encode definition-query.
      3. INFORMATION_SCHEMA used strings with mixed encodings to display object
         definition;
      
      1. No query-definition-character set.
      
      In order to compile query into execution code, some extra data (such as
      environment variables or the database character set) is used. The problem
      here was that this context was not preserved. So, on the next load it can
      differ from the original one, thus the result will be different.
      
      The context contains the following data:
        - client character set;
        - connection collation (character set and collation);
        - collation of the owner database;
      
      The fix is to store this context and use it each time we parse (compile)
      and execute the object (stored routine, trigger, ...).
      
      2. Wrong mysqldump-output.
      
      The original query can contain several encodings (by means of character set
      introducers). The problem here was that we tried to convert original query
      to the mysqldump-client character set.
      
      Moreover, we stored queries in different character sets for different
      objects (views, for one, used UTF8, triggers used original character set).
      
      The solution is
        - to store definition queries in the original character set;
        - to change SHOW CREATE statement to output definition query in the
          binary character set (i.e. without any conversion);
        - introduce SHOW CREATE TRIGGER statement;
        - to dump special statements to switch the context to the original one
          before dumping and restore it afterwards.
      
      Note, in order to preserve the database collation at the creation time,
      additional ALTER DATABASE might be used (to temporary switch the database
      collation back to the original value). In this case, ALTER DATABASE
      privilege will be required. This is a backward-incompatible change.
      
      3. INFORMATION_SCHEMA showed non-UTF8 strings
      
      The fix is to generate UTF8-query during the parsing, store it in the object
      and show it in the INFORMATION_SCHEMA.
      
      Basically, the idea is to create a copy of the original query convert it to
      UTF8. Character set introducers are removed and all text literals are
      converted to UTF8.
      
      This UTF8 query is intended to provide user-readable output. It must not be
      used to recreate the object.  Specialized SHOW CREATE statements should be
      used for this.
      
      The reason for this limitation is the following: the original query can
      contain symbols from several character sets (by means of character set
      introducers).
      
      Example:
      
        - original query:
          CREATE VIEW v1 AS SELECT _cp1251 'Hello' AS c1;
      
        - UTF8 query (for INFORMATION_SCHEMA):
          CREATE VIEW v1 AS SELECT 'Hello' AS c1;
      9fae9ef6
  38. 19 Jun, 2007 1 commit
    • gkodinov/kgeorge@magare.gmz's avatar
      Bug #26418: Slave out of sync after · bef15b27
      gkodinov/kgeorge@magare.gmz authored
       CREATE/DROP TEMPORARY TABLE + ROLLBACK on master
      
      The transaction ability of the storage engines of
      the tables on the replication master and the replication
      slave must generally be the same.
      When the storage engine type of the slave is 
      non-transactional then transactions on the master that 
      mix update of transactional and non-transactional tables
      should be avoided because they will cause inconsistency of
      the data between the master's transactional table and the
      slave's non-transactional table.
      
      The effect described by this bug is actually expected.
      A detailed test case is added (to be merged later to
      the updated rpl_ddl.test), as there was no coverage 
      by the existing tests. 
      Some code cleanup is also added by this change.
      bef15b27