An error occurred fetching the project authors.
  1. 17 Mar, 2010 1 commit
    • Luis Soares's avatar
      BUG#51426: overflow for auto_increment column causes slave to stop · 229da7c0
      Luis Soares authored
      In BUG#49562 we fixed the case where numeric user var events
      would not serialize the flag stating whether the value was signed
      or unsigned (unsigned_flag). This fixed the case that the slave
      would get an overflow while treating the unsigned values as
      signed.
            
      In this bug, we find that the unsigned_flag can sometimes change
      between the moment that the user value is recorded for binlogging
      purposes and the actual binlogging time. Since we take the
      unsigned_flag from the runtime variable data, at binlogging time,
      and the variable value is comes from the copy taken earlier in
      the execution, there may be inconsistency in the
      User_var_log_event between the variable value and its
      unsigned_flag.
            
      We fix this by also copying the unsigned_flag of the
      user_var_entry when its value is copied, for binlogging
      purposes. Later, at binlogging time, we use the copied
      unsigned_flag and not the one in the runtime user_var_entry
      instance.
      229da7c0
  2. 13 Mar, 2010 1 commit
  3. 03 Mar, 2010 1 commit
  4. 24 Feb, 2010 1 commit
    • Jon Olav Hauglid's avatar
      Followup to Bug#45225 Locking: hang if drop table with no timeout · dd42aab8
      Jon Olav Hauglid authored
      This patch prevents system threads and system table accesses from
      using user-specified values for "lock_wait_timeout". Instead all
      such accesses are done using the default value (1 year).
      
      This prevents background tasks (such as replication, events, 
      accessing stored function definitions, logging, reading time-zone
      information, etc.) from failing in cases where the global value
      of "lock_wait_timeout" is set very low.
      
      The patch also simplifies the open tables API. Rather than adding
      another convenience function for opening and locking system tables,
      this patch removes most of the existing convenience functions for
      open_and_lock_tables_derived(). Before, open_and_lock_tables() was
      a convenience function that enforced derived tables handling, while
      open_and_lock_tables_derived() was the main function where derived
      tables handling was optional. Now, this convencience function is
      gone and the main function is renamed to open_and_lock_tables(). 
      
      No test case added as it would have required the use of --sleep to
      check that system threads and system tables have a different timeout
      value from the user-specified "lock_wait_timeout" system variable.
      dd42aab8
  5. 22 Feb, 2010 1 commit
  6. 18 Feb, 2010 1 commit
  7. 15 Feb, 2010 1 commit
  8. 12 Feb, 2010 1 commit
    • Dmitry Lenev's avatar
      Fix for bug #50908 "Assertion `handler_tables_hash.records == 0' · 0ec868ca
      Dmitry Lenev authored
      failed in enter_locked_tables_mode".
      
      Server was aborted due to assertion failure when one tried to 
      execute statement requiring prelocking (i.e. firing triggers
      or using stored functions) while having open HANDLERs.
      
      The problem was that THD::enter_locked_tables_mode() method
      which was called at the beginning of execution of prelocked 
      statement assumed there are no open HANDLERs. It had to do 
      so because corresponding THD::leave_locked_tables_mode()
      method was unable to properly restore MDL sentinel when
      leaving LOCK TABLES/prelocked mode in the presence of open 
      HANDLERs.
      
      This patch solves this problem by changing the latter method
      to properly restore MDL sentinel and thus removing need for 
      this assumption. As a side-effect, it lifts unjustified
      limitation by allowing to keep HANDLERs open when entering 
      LOCK TABLES mode.
      0ec868ca
  9. 11 Feb, 2010 1 commit
    • Jon Olav Hauglid's avatar
      Bug #45225 Locking: hang if drop table with no timeout · 5bb67f34
      Jon Olav Hauglid authored
      This patch introduces timeouts for metadata locks. 
      
      The timeout is specified in seconds using the new dynamic system 
      variable  "lock_wait_timeout" which has both GLOBAL and SESSION
      scopes. Allowed values range from 1 to 31536000 seconds (= 1 year). 
      The default value is 1 year.
      
      The new server parameter "lock-wait-timeout" can be used to set
      the default value parameter upon server startup.
      
      "lock_wait_timeout" applies to all statements that use metadata locks.
      These include DML and DDL operations on tables, views, stored procedures
      and stored functions. They also include LOCK TABLES, FLUSH TABLES WITH
      READ LOCK and HANDLER statements.
      
      The patch also changes thr_lock.c code (table data locks used by MyISAM
      and other simplistic engines) to use the same system variable.
      InnoDB row locks are unaffected.
      
      One exception to the handling of the "lock_wait_timeout" variable
      is delayed inserts. All delayed inserts are executed with a timeout
      of 1 year regardless of the setting for the global variable. As the
      connection issuing the delayed insert gets no notification of 
      delayed insert timeouts, we want to avoid unnecessary timeouts.
      
      It's important to note that the timeout value is used for each lock
      acquired and that one statement can take more than one lock.
      A statement can therefore block for longer than the lock_wait_timeout 
      value before reporting a timeout error. When lock timeout occurs, 
      ER_LOCK_WAIT_TIMEOUT is reported.
      
      Test case added to lock_multi.test.
      5bb67f34
  10. 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
  11. 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
  12. 03 Feb, 2010 1 commit
    • MySQL Build Team's avatar
      Backport into build-201002030816-5.0.87sp1 · cb6780d2
      MySQL Build Team authored
      > ------------------------------------------------------------
      > revno: 2818.1.40 [merge]
      > revision-id: epotemkin@mysql.com-20091202134712-4muwnr152xqkcwm7
      > parent: gshchepa@mysql.com-20091201102444-yw166t3audrojo9s
      > parent: epotemkin@mysql.com-20091201182845-aw0uawt6c6gwi98c
      > committer: Evgeny Potemkin <epotemkin@mysql.com>
      > branch nick: mysql-5.0-bugteam
      > timestamp: Wed 2009-12-02 16:47:12 +0300
      > message:
      >   Auto-merged fix for the bug#48508.
      > ------------------------------------------------------------
      > Use --include-merges or -n0 to see merged revisions.
      cb6780d2
  13. 01 Feb, 2010 1 commit
    • Dmitry Lenev's avatar
      Implement new type-of-operation-aware metadata locks. · afd15c43
      Dmitry Lenev authored
      Add a wait-for graph based deadlock detector to the
      MDL subsystem.
      
      Fixes bug #46272 "MySQL 5.4.4, new MDL: unnecessary deadlock" and
      bug #37346 "innodb does not detect deadlock between update and
      alter table".
      
      The first bug manifested itself as an unwarranted abort of a
      transaction with ER_LOCK_DEADLOCK error by a concurrent ALTER
      statement, when this transaction tried to repeat use of a
      table, which it has already used in a similar fashion before
      ALTER started.
      
      The second bug showed up as a deadlock between table-level
      locks and InnoDB row locks, which was "detected" only after
      innodb_lock_wait_timeout timeout.
      
      A transaction would start using the table and modify a few
      rows.
      Then ALTER TABLE would come in, and start copying rows
      into a temporary table. Eventually it would stumble on
      the modified records and get blocked on a row lock.
      The first transaction would try to do more updates, and get
      blocked on thr_lock.c lock.
      This situation of circular wait would only get resolved
      by a timeout.
      
      Both these bugs stemmed from inadequate solutions to the
      problem of deadlocks occurring between different
      locking subsystems.
      
      In the first case we tried to avoid deadlocks between metadata
      locking and table-level locking subsystems, when upgrading shared
      metadata lock to exclusive one.
      Transactions holding the shared lock on the table and waiting for
      some table-level lock used to be aborted too aggressively.
      
      We also allowed ALTER TABLE to start in presence of transactions
      that modify the subject table. ALTER TABLE acquires
      TL_WRITE_ALLOW_READ lock at start, and that block all writes
      against the table (naturally, we don't want any writes to be lost
      when switching the old and the new table). TL_WRITE_ALLOW_READ
      lock, in turn, would block the started transaction on thr_lock.c
      lock, should they do more updates. This, again, lead to the need
      to abort such transactions.
      
      The second bug occurred simply because we didn't have any
      mechanism to detect deadlocks between the table-level locks
      in thr_lock.c and row-level locks in InnoDB, other than
      innodb_lock_wait_timeout.
      
      This patch solves both these problems by moving lock conflicts
      which are causing these deadlocks into the metadata locking
      subsystem, thus making it possible to avoid or detect such
      deadlocks inside MDL.
      
      To do this we introduce new type-of-operation-aware metadata
      locks, which allow MDL subsystem to know not only the fact that
      transaction has used or is going to use some object but also what
      kind of operation it has carried out or going to carry out on the
      object.
      
      This, along with the addition of a special kind of upgradable
      metadata lock, allows ALTER TABLE to wait until all
      transactions which has updated the table to go away.
      This solves the second issue.
      Another special type of upgradable metadata lock is acquired
      by LOCK TABLE WRITE. This second lock type allows to solve the
      first issue, since abortion of table-level locks in event of
      DDL under LOCK TABLES becomes also unnecessary.
      
      Below follows the list of incompatible changes introduced by
      this patch:
      
      - From now on, ALTER TABLE and CREATE/DROP TRIGGER SQL (i.e. those
        statements that acquire TL_WRITE_ALLOW_READ lock)
        wait for all transactions which has *updated* the table to
        complete.
      
      - From now on, LOCK TABLES ... WRITE, REPAIR/OPTIMIZE TABLE
        (i.e. all statements which acquire TL_WRITE table-level lock) wait
        for all transaction which *updated or read* from the table
        to complete.
        As a consequence, innodb_table_locks=0 option no longer applies
        to LOCK TABLES ... WRITE.
      
      - DROP DATABASE, DROP TABLE, RENAME TABLE no longer abort
        statements or transactions which use tables being dropped or
        renamed, and instead wait for these transactions to complete.
      
      - Since LOCK TABLES WRITE now takes a special metadata lock,
        not compatible with with reads or writes against the subject table
        and transaction-wide, thr_lock.c deadlock avoidance algorithm
        that used to ensure absence of deadlocks between LOCK TABLES
        WRITE and other statements is no longer sufficient, even for
        MyISAM. The wait-for graph based deadlock detector of MDL
        subsystem may sometimes be necessary and is involved. This may
        lead to ER_LOCK_DEADLOCK error produced for multi-statement
        transactions even if these only use MyISAM:
      
        session 1:         session 2:
        begin;
      
        update t1 ...      lock table t2 write, t1 write;
                           -- gets a lock on t2, blocks on t1
      
        update t2 ...
        (ER_LOCK_DEADLOCK)
      
      - Finally,  support of LOW_PRIORITY option for LOCK TABLES ... WRITE
        was abandoned.
        LOCK TABLE ... LOW_PRIORITY WRITE from now on has the same
        priority as the usual LOCK TABLE ... WRITE.
        SELECT HIGH PRIORITY no longer trumps LOCK TABLE ... WRITE  in
        the wait queue.
      
      - We do not take upgradable metadata locks on implicitly
        locked tables. So if one has, say, a view v1 that uses
        table t1, and issues:
        LOCK TABLE v1 WRITE;
        FLUSH TABLE t1; -- (or just 'FLUSH TABLES'),
        an error is produced.
        In order to be able to perform DDL on a table under LOCK TABLES,
        the table must be locked explicitly in the LOCK TABLES list.
      afd15c43
  14. 10 Feb, 2010 1 commit
    • Martin Hansson's avatar
      Bug#49534: multitable IGNORE update with sql_safe_updates · 2a22dc2e
      Martin Hansson authored
      error causes debug assertion
      
      The IGNORE option of the multiple-table UPDATE command was
      not intended to suppress errors caused by the
      sql_safe_updates mode. This flag will raise an error if the
      execution of UPDATE does not use a key for row retrieval,
      and should continue do so regardless of the IGNORE option.
      
      However the implementation of IGNORE does not support
      exceptions to the rule; it always converts errors to
      warnings and cannot be extended. The Internal_error_handler
      interface offers the infrastructure to handle individual
      errors, making sure that the error raised by
      sql_safe_updates is not silenced.
      
      Fixed by implementing an Internal_error_handler and using it
      for UPDATE IGNORE commands.
      2a22dc2e
  15. 24 Jan, 2010 1 commit
  16. 21 Jan, 2010 2 commits
    • 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
    • Alfranio Correia's avatar
      BUG#46364 MyISAM transbuffer problems (NTM problem) · 8da3fea2
      Alfranio Correia authored
            
      It is well-known that due to concurrency issues, a slave can become
      inconsistent when a transaction contains updates to both transaction and
      non-transactional tables.
                          
      In a nutshell, the current code-base tries to preserve causality among the
      statements by writing non-transactional statements to the txn-cache which
      is flushed upon commit. However, modifications done to non-transactional
      tables on behalf of a transaction become immediately visible to other
      connections but may not immediately get into the binary log and therefore
      consistency may be broken.
                  
      In general, it is impossible to automatically detect causality/dependency
      among statements by just analyzing the statements sent to the server. This
      happen because dependency may be hidden in the application code and it is
      necessary to know a priori all the statements processed in the context of
      a transaction such as in a procedure. Moreover, even for the few cases that
      we could automatically address in the server, the computation effort
      required could make the approach infeasible.
                  
      So, in this patch we introduce the option
            - "--binlog-direct-non-transactional-updates" that can be used to bypass
            the current behavior in order to write directly to binary log statements
            that change non-transactional tables.
      
      Besides, it is used to enable the WL#2687 which is disabled by default.
      8da3fea2
  17. 20 Jan, 2010 1 commit
    • Alfranio Correia's avatar
      BUG#46364 MyISAM transbuffer problems (NTM problem) · 0aa3aee0
      Alfranio Correia authored
      It is well-known that due to concurrency issues, a slave can become
      inconsistent when a transaction contains updates to both transaction and
      non-transactional tables in statement and mixed modes.
      
      In a nutshell, the current code-base tries to preserve causality among the
      statements by writing non-transactional statements to the txn-cache which
      is flushed upon commit. However, modifications done to non-transactional
      tables on behalf of a transaction become immediately visible to other
      connections but may not immediately get into the binary log and therefore
      consistency may be broken.
      
      In general, it is impossible to automatically detect causality/dependency
      among statements by just analyzing the statements sent to the server. This
      happen because dependency may be hidden in the application code and it is
      necessary to know a priori all the statements processed in the context of
      a transaction such as in a procedure. Moreover, even for the few cases that
      we could automatically address in the server, the computation effort
      required could make the approach infeasible.
      
      So, in this patch we introduce the option
          - "--binlog-direct-non-transactional-updates" that can be used to bypass
          the current behavior in order to write directly to binary log statements
          that change non-transactional tables.
      0aa3aee0
  18. 07 Jan, 2010 1 commit
  19. 30 Dec, 2009 1 commit
    • Dmitry Lenev's avatar
      Implementation of simple deadlock detection for metadata locks. · 236539b4
      Dmitry Lenev authored
      This change is supposed to reduce number of ER_LOCK_DEADLOCK
      errors which occur when multi-statement transaction encounters
      conflicting metadata lock in cases when waiting is possible.
      
      The idea is not to fail ER_LOCK_DEADLOCK error immediately when
      we encounter conflicting metadata lock. Instead we release all
      metadata locks acquired by current statement and start to wait
      until conflicting lock go away. To avoid deadlocks we use simple
      empiric which aborts waiting with ER_LOCK_DEADLOCK error if it
      turns out that somebody is waiting for metadata locks owned by
      this transaction.
      
      This patch also fixes bug #46273 "MySQL 5.4.4 new MDL: Bug#989
      is not fully fixed in case of ALTER".
      
      The bug was that concurrent execution of UPDATE or MULTI-UPDATE
      statement as a part of multi-statement transaction that already
      has used table being updated and ALTER TABLE statement might have
      resulted of loss of isolation between this transaction and ALTER
      TABLE statement, which manifested itself as changes performed by
      ALTER TABLE becoming visible in transaction and wrong binary log
      order as a consequence.
      
      This problem occurred when UPDATE or MULTI-UPDATE's wait in
      mysql_lock_tables() call was aborted due to metadata lock
      upgrade performed by concurrent ALTER TABLE. After such abort all
      metadata locks held by transaction were released but transaction
      silently continued to be executed as if nothing has happened.
      
      We solve this problem by changing our code not to release all
      locks in such case. Instead we release only locks which were
      acquired by current statement and then try to reacquire them
      by restarting open/lock tables process. We piggyback on simple
      deadlock detector implementation since this change has to be
      done anyway for it.
      236539b4
  20. 29 Dec, 2009 1 commit
    • Konstantin Osipov's avatar
      Apply and review: · 3b311f39
      Konstantin Osipov authored
      3655 Jon Olav Hauglid   2009-10-19
      Bug #30977 Concurrent statement using stored function and DROP FUNCTION 
                 breaks SBR
      Bug #48246 assert in close_thread_table
      
      Implement a fix for:
      Bug #41804 purge stored procedure cache causes mysterious hang for many
                 minutes
      Bug #49972 Crash in prepared statements
      
      The problem was that concurrent execution of DML statements that
      use stored functions and DDL statements that drop/modify the same
      function might result in incorrect binary log in statement (and
      mixed) mode and therefore break replication.
      
      This patch fixes the problem by introducing metadata locking for
      stored procedures and functions. This is similar to what is done
      in Bug#25144 for views. Procedures and functions now are
      locked using metadata locks until the transaction is either
      committed or rolled back. This prevents other statements from
      modifying the procedure/function while it is being executed. This
      provides commit ordering - guaranteeing serializability across
      multiple transactions and thus fixes the reported binlog problem.
      
      Note that we do not take locks for top-level CALLs. This means
      that procedures called directly are not protected from changes by
      simultaneous DDL operations so they are executed at the state they
      had at the time of the CALL. By not taking locks for top-level
      CALLs, we still allow transactions to be started inside
      procedures.
      
      This patch also changes stored procedure cache invalidation.
      Upon a change of cache version, we no longer invalidate the entire
      cache, but only those routines which we use, only when a statement
      is executed that uses them.
      
      This patch also changes the logic of prepared statement validation.
      A stored procedure used by a prepared statement is now validated
      only once a metadata lock has been acquired. A version mismatch
      causes a flush of the obsolete routine from the cache and
      statement reprepare.
      Incompatible changes:
      1) ER_LOCK_DEADLOCK is reported for a transaction trying to access
         a procedure/function that is locked by a DDL operation in
         another connection.
      
      2) Procedure/function DDL operations are now prohibited in LOCK
         TABLES mode as exclusive locks must be taken all at once and
         LOCK TABLES provides no way to specifiy procedures/functions to
         be locked.
      
      Test cases have been added to sp-lock.test and rpl_sp.test.
      
      Work on this bug has very much been a team effort and this patch
      includes and is based on contributions from Davi Arnaut, Dmitry
      Lenev, Magne Mæhre and Konstantin Osipov.
      3b311f39
  21. 22 Dec, 2009 2 commits
    • Konstantin Osipov's avatar
      A prerequisite patch for the fix for Bug#46224 · 39a1a50d
      Konstantin Osipov authored
      "HANDLER statements within a transaction might lead to deadlocks".
      Introduce a notion of a sentinel to MDL_context. A sentinel
      is a ticket that separates all tickets in the context into two
      groups: before and after it. Currently we can have (and need) only
      one designated sentinel -- it separates all locks taken by LOCK
      TABLE or HANDLER statement, which must survive COMMIT and ROLLBACK
      and all other locks, which must be released at COMMIT or ROLLBACK.
      The tricky part is maintaining the sentinel up to date when
      someone release its corresponding ticket. This can happen, e.g.
      if someone issues DROP TABLE under LOCK TABLES (generally,
      see all calls to release_all_locks_for_name()).
      MDL_context::release_ticket() is modified to take care of it.
      
      ******
      A fix and a test case for Bug#46224 "HANDLER statements within a
      transaction might lead to deadlocks".
      
      An attempt to mix HANDLER SQL statements, which are transaction-
      agnostic, an open multi-statement transaction,
      and DDL against the involved tables (in a concurrent connection) 
      could lead to a deadlock. The deadlock would occur when
      HANDLER OPEN or HANDLER READ would have to wait on a conflicting
      metadata lock. If the connection that issued HANDLER statement
      also had other metadata locks (say, acquired in scope of a 
      transaction), a classical deadlock situation of mutual wait
      could occur.
      
      Incompatible change: entering LOCK TABLES mode automatically
      closes all open HANDLERs in the current connection.
      
      Incompatible change: previously an attempt to wait on a lock
      in a connection that has an open HANDLER statement could wait
      indefinitely/deadlock. After this patch, an error ER_LOCK_DEADLOCK
      is produced.
      
      The idea of the fix is to merge thd->handler_mdl_context
      with the main mdl_context of the connection, used for transactional
      locks. This makes deadlock detection possible, since all waits
      with locks are "visible" and available to analysis in a single
      MDL context of the connection.
      
      Since HANDLER locks and transactional locks have a different life
      cycle -- HANDLERs are explicitly open and closed, and so
      are HANDLER locks, explicitly acquired and released, whereas
      transactional locks "accumulate" till the end of a transaction
      and are released only with COMMIT, ROLLBACK and ROLLBACK TO SAVEPOINT,
      a concept of "sentinel" was introduced to MDL_context.
      All locks, HANDLER and others, reside in the same linked list.
      However, a selected element of the list separates locks with
      different life cycle. HANDLER locks always reside at the
      end of the list, after the sentinel. Transactional locks are
      prepended to the beginning of the list, before the sentinel.
      Thus, ROLLBACK, COMMIT or ROLLBACK TO SAVEPOINT, only
      release those locks that reside before the sentinel. HANDLER locks
      must be released explicitly as part of HANDLER CLOSE statement,
      or an implicit close. 
      The same approach with sentinel
      is also employed for LOCK TABLES locks. Since HANDLER and LOCK TABLES
      statement has never worked together, the implementation is
      made simple and only maintains one sentinel, which is used either
      for HANDLER locks, or for LOCK TABLES locks.
      39a1a50d
    • 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
  22. 15 Dec, 2009 1 commit
    • Sergey Vojtovich's avatar
      Backport from 6.0-codebase. · 94098b22
      Sergey Vojtovich authored
      WL#3771
        "Audit Plugin Interface"
        Implement new plug-in type - AUDIT
        New plug-in: audit_null
          simply increments counter for how many times it was called.
      94098b22
  23. 14 Dec, 2009 1 commit
    • Mats Kindahl's avatar
      WL#5151: Conversion between different types when replicating · c63df11f
      Mats Kindahl authored
      Row-based replication requires the types of columns on the
      master and slave to be approximately the same (some safe
      conversions between strings are allowed), but does not
      allow safe conversions between fields of similar types such
      as TINYINT and INT.
      
      This patch implement type conversions between similar fields
      on the master and slave.
      
      The conversions are controlled using a new variable
      SLAVE_TYPE_CONVERSIONS of type SET('ALL_LOSSY','ALL_NON_LOSSY').
      
      Non-lossy conversions are any conversions that do not run the
      risk of losing any information, while lossy conversions can
      potentially truncate the value. The column definitions are
      checked to decide if the conversion is acceptable.
      
      If neither conversion is enabled, it is required that the
      definitions of the columns are identical on master and slave.
      
      Conversion is done by creating an internal conversion table,
      unpacking the master data into it, and then copy the data to
      the real table on the slave.
      c63df11f
  24. 10 Dec, 2009 2 commits
    • Jon Olav Hauglid's avatar
      Backport of revno: 3685 · 87243209
      Jon Olav Hauglid authored
      Bug #48210 FLUSH TABLES WITH READ LOCK deadlocks
                 against concurrent CREATE PROCEDURE
      
      This deadlock occured between
      a) CREATE PROCEDURE (or other commands listed below)
      b) FLUSH TABLES WITH READ LOCK
      
      If the execution of them happened in the following order:
      - a) opens a table (e.g. mysql.proc)
      - b) locks the global read lock (or GRL)
      - a) sleeps inside wait_if_global_read_lock()
      - b) increases refresh_version and sleeps waiting 
           for old tables to go away
      
      Note that a) must start waiting on the GRL before FLUSH increases
      refresh_version. Otherwise a) won't wait on the GRL and instead
      close its tables for reopen, allowing FLUSH to complete and thus
      avoid the deadlock.
      
      With this patch the deadlock is avoided by making CREATE PROCEDURE
      acquire a protection against global read locks before it starts
      executing. This means that FLUSH TABLES WITH READ LOCK will have
      to wait until CREATE PROCEDURE completes before acquiring the global
      read lock, thereby avoiding the deadlock.
      
      This is implemented by introducing a new SQL command flag called
      CF_PROTECT_AGAINST_GRL. Commands marked with this flag will
      acquire a GRL protection in the beginning of mysql_execute_command().
      This patch adds the flag to CREATE, ALTER and DROP for PROCEDURE
      and FUNCTION, as well as CREATE USER, DROP USER, RENAME USER and 
      REVOKE ALL. All these commands either call open_grant_tables() or
      open_system_table_for_updated() which make them susceptible for
      this deadlock.
      
      The patch also adds the CF_PROTECT_AGAINST_GRL flag to a number
      of commands that previously acquired GRL protection in their
      respective SQLCOM case in mysql_execute_command().
      
      Test case that checks for GRL protection for CREATE PROCEDURE
      and CREATE USER added to mdl_sync.test.
      87243209
    • Marc Alff's avatar
      WL#2360 Performance schema · e33a8b2a
      Marc Alff authored
      Part III: mysys instrumentation
      e33a8b2a
  25. 09 Dec, 2009 1 commit
    • Jon Olav Hauglid's avatar
      Backport of revno: 2617.68.13 · 17252c32
      Jon Olav Hauglid authored
      Introduce a counter for protection against global read lock on thread level.
      
      The functions for protection against global read lock sometimes need a local
      variable to signal when the protection is set, and hence need to be released.
      It would be better to control this behaviour via a counter on the THD struct,
      telling how many times the protection has been claimed by the current thread.
      A side-effect of the fix is that if protection is claimed twice for a thread,
      only a simple increment is required for the second claim, instead of a
      mutex-protected increment of the global variable protect_against_global_read_lock.
      17252c32
  26. 08 Dec, 2009 4 commits
    • Jon Olav Hauglid's avatar
      Backport of revno: 2617.65.10 · f28f9859
      Jon Olav Hauglid authored
      Bug #45067 Assertion `stmt_da->is_error()' in 
                 Delayed_insert::open_and_lock_table
      
      The assert was triggered when delayed insert was killed by another 
      connection using mysql_notify_thread_having_shared_lock().
      During handling of thd->killed, thd.fatal_error() was called without
      a previous call to my_error() which triggered the assert.
      This patch allows the assert to pass if thd->killed has been set.
      f28f9859
    • Konstantin Osipov's avatar
      Backport of: · c20afa6d
      Konstantin Osipov authored
      ----------------------------------------------------------
      revno: 2617.69.24
      committer: Konstantin Osipov <kostja@sun.com>
      branch nick: 5.4-42546
      timestamp: Fri 2009-08-14 19:22:05 +0400
      message:
        A pre-requisite for a fix for Bug#42546 "Backup: RESTORE fails, thinking it
        finds an existing table"
        Back-port from WL 148 "Foreign keys" feature tree a patch
        that introduced Prelocking_strategy class -- a way to parameterize
        open_tables() behaviour, implemented by Dmitry Lenev.
      
      (Part of WL#4284).
      c20afa6d
    • Konstantin Osipov's avatar
      Backport of: · a66a2608
      Konstantin Osipov authored
      ----------------------------------------------------------
      revno: 2617.69.20
      committer: Konstantin Osipov <kostja@sun.com>
      branch nick: 5.4-4284-1-assert
      timestamp: Thu 2009-08-13 18:29:55 +0400
      message:
        WL#4284 "Transactional DDL locking"
        A review fix.
        Since WL#4284 implementation separated MDL_request and MDL_ticket,
        MDL_request becamse a utility object necessary only to get a ticket.
        Store it by-value in TABLE_LIST with the intent to merge
        MDL_request::key with table_list->table_name and table_list->db
        in future.
        Change the MDL subsystem to not require MDL_requests to
        stay around till close_thread_tables().
        Remove the list of requests from the MDL context.
        Requests for shared metadata locks acquired in open_tables()
        are only used as a list in recover_from_failed_open_table_attempt(),
        which calls mdl_context.wait_for_locks() for this list.
        To keep such list for recover_from_failed_open_table_attempt(),
        introduce a context class (Open_table_context), that collects
        all requests.
        A lot of minor cleanups and simplications that became possible
        with this change.
      a66a2608
    • Konstantin Osipov's avatar
      Backport of: · 4a8a1c56
      Konstantin Osipov authored
      ----------------------------------------------------------
      revno: 2617.69.2
      committer: Konstantin Osipov <kostja@sun.com>
      branch nick: 5.4-azalea-bugfixing
      timestamp: Mon 2009-08-03 19:26:04 +0400
      message:
        A fix and a test case for Bug#45035 "Altering table under LOCK TABLES
        results in "Error 1213 Deadlock found...".
      
        If a user had a table locked with LOCK TABLES
        for READ and for WRITE in the same connection, ALTER TABLE
        could fail.
      
        Root cause analysis:
      
        If a connection issues
      
        LOCK TABLE t1 write, t1 a read, t1 b read;
      
        the new LOCK TABLES code in 6.0 (part of WL 3726) will create
        the following list of TABLE_LIST objects
        (thd->locked_tables_list->m_locked_tables):
      
        {"t1" "b" tl_read_no_insert}, {"t1" "a" tl_read_no_insert},
        {"t1" "t1" tl_write }
      
        Later on, when we try to ALTER table t1, mysql_alter_table()
        closes all TABLE instances and releases its thr_lock locks,
        keeping only an exclusive metadata lock on t1.
      
        But when ALTER is finished, Locked_table_list::reopen_tables()
        tries to restore the original list of open and locked tables.
      
        Before this patch, it used to do so one by one:
        Open t1 b, get TL_READ_NO_INSERT lock,
        Open t1 a, get TL_READ_NO_INSERT lock
        Open t1, try to get TL_WRITE lock, deadlock.
      
        The cause of the deadlock is that thr_lock.c doesn't
        resolve the situation when the read list only consists
        of locks taken by the same thread, followed by this very
        thread trying to take a WRITE lock. Indeed, since
        thr_lock_multi always gets a sorted list of locks,
        WRITE locks always precede READ locks in the list
        to lock.
      
        Don't try to fix thr_lock.c deficiency, keep this
        code simple.
        Instead, try to take all thr_lock locks at once
        in ::reopen_tables().
      4a8a1c56
  27. 05 Dec, 2009 1 commit
  28. 03 Dec, 2009 5 commits
    • Konstantin Osipov's avatar
      Backport of: · a3a23ec4
      Konstantin Osipov authored
      ----------------------------------------------------------
      revno: 2617.23.20
      committer: Konstantin Osipov <kostja@sun.com>
      branch nick: mysql-6.0-runtime
      timestamp: Wed 2009-03-04 16:31:31 +0300
      message:
        WL#4284 "Transactional DDL locking"
        Review comments: "Objectify" the MDL API.
        MDL_request and MDL_context still need manual construction and
        destruction, since they are used in environment that is averse
        to constructors/destructors.
      a3a23ec4
    • Konstantin Osipov's avatar
      Backport of: · 911c673e
      Konstantin Osipov authored
      ------------------------------------------------------------
      revno: 2617.23.18
      committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
      branch nick: 4284-6.0
      timestamp: Mon 2009-03-02 18:18:26 -0300
      message:
      Bug#989: If DROP TABLE while there's an active transaction, wrong binlog order
      WL#4284: Transactional DDL locking
      
      This is a prerequisite patch:
      
      These changes are intended to split lock requests from granted
      locks and to allow the memory and lifetime of granted locks to
      be managed within the MDL subsystem. Furthermore, tickets can
      now be shared and therefore are used to satisfy multiple lock
      requests, but only shared locks can be recursive.
      
      The problem is that the MDL subsystem morphs lock requests into
      granted locks locks but does not manage the memory and lifetime
      of lock requests, and hence, does not manage the memory of
      granted locks either. This can be problematic because it puts the
      burden of tracking references on the users of the subsystem and
      it can't be easily done in transactional contexts where the locks
      have to be kept around for the duration of a transaction.
      
      Another issue is that recursive locks (when the context trying to
      acquire a lock already holds a lock on the same object) requires
      that each time the lock is granted, a unique lock request/granted
      lock structure structure must be kept around until the lock is
      released. This can lead to memory leaks in transactional contexts
      as locks taken during the transaction should only be released at
      the end of the transaction. This also leads to unnecessary wake
      ups (broadcasts) in the MDL subsystem if the context still holds
      a equivalent of the lock being released.
      
      These issues are exacerbated due to the fact that WL#4284 low-level
      design says that the implementation should "2) Store metadata locks
      in transaction memory root, rather than statement memory root" but
      this is not possible because a memory root, as implemented in mysys,
      requires all objects allocated from it to be freed all at once.
      
      This patch combines review input and significant code contributions
      from Konstantin Osipov (kostja) and Dmitri Lenev (dlenev).
      911c673e
    • Konstantin Osipov's avatar
      ------------------------------------------------------------ · 67c1b06f
      Konstantin Osipov authored
      revno: 2617.22.4
      committer: Davi Arnaut <Davi.Arnaut@Sun.COM>
      branch nick: mysql-6.0-runtime
      timestamp: Mon 2009-01-26 15:19:14 -0200
      message:
      Move checks for OPTION_NOT_AUTOCOMMIT | OPTION_BEGIN to a separate
      helper function.
      67c1b06f
    • 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
    • Konstantin Osipov's avatar
      Backport of: · 45a5d797
      Konstantin Osipov authored
      ------------------------------------------------------------
      revno: 2630.4.39
      committer: Dmitry Lenev <dlenev@mysql.com>
      branch nick: mysql-6.0-3726-w2
      timestamp: Thu 2008-06-26 13:08:27 +0400
      message:
        Fix warnings about passing pointer to not fully-initialized THD
        object to constructor of base Open_tables_state classe, which
        appeared on Windows and were introduced by one of the patches
        implementing WL#3726 "DDL locking for all metadata objects".
      45a5d797
  29. 02 Dec, 2009 1 commit
    • Konstantin Osipov's avatar
      Backport of: · bcae0d9b
      Konstantin Osipov authored
      ----------------------------------------------------------
      revno: 2630.10.1
      committer: Konstantin Osipov <konstantin@mysql.com>
      branch nick: mysql-6.0-lock-tables-tidyup
      timestamp: Wed 2008-06-11 15:49:58 +0400
      message:
        WL#3726, review fixes.
        Now that we have metadata locks, we don't need to keep a crippled
        TABLE instance in the table cache to indicate that a table is locked.
        Remove all code that used this technique. Instead, rely on metadata
        locks and use the standard open_table() and close_thread_table()
        to manipulate with the table cache tables.
        Removes a list of functions that have become unused (see the comment
        for sql_base.cc for details).
        Under LOCK TABLES, keep a TABLE_LIST instance for each table
        that may be temporarily closed. For that, implement an own class for
        LOCK TABLES mode, Locked_tables_list.
      
      This is a pre-requisite patch for WL#4144.
      This is not exactly a backport: there is no new 
      online ALTER table in Celosia, so the old alter table
      code was changed to work with the new table cache API.
      bcae0d9b
  30. 01 Dec, 2009 1 commit
    • Evgeny Potemkin's avatar
      Bug#48508: Crash on prepared statement re-execution. · 1db3a684
      Evgeny Potemkin authored
      Actually there is two different bugs.
      The first one caused crash on queries with WHERE condition over views
      containing WHERE condition. A wrong check for prepared statement phase led
      to items for view fields being allocated in the execution memory and freed
      at the end of execution. Thus the optimized WHERE condition refers to
      unallocated memory on the second execution and server crashed.
      The second one caused by the Item_cond::compile function not saving changes
      it made to the item tree. Thus on the next execution changes weren't
      reverted and server crashed on dereferencing of unallocated space.
      
      The new helper function called is_stmt_prepare_or_first_stmt_execute
      is added to the Query_arena class.
      The find_field_in_view function now uses
      is_stmt_prepare_or_first_stmt_execute() to check whether
      newly created view items should be freed at the end of the query execution.
      The Item_cond::compile function now saves changes it makes to item tree.
      1db3a684