An error occurred fetching the project authors.
  1. 08 Jul, 2014 2 commits
  2. 21 Mar, 2014 1 commit
    • unknown's avatar
      MDEV-5914: Parallel replication deadlock due to InnoDB lock conflicts · b3529691
      unknown authored
      Due to how gap locks work, two transactions could group commit together on the
      master, but get lock conflicts and then deadlock due to different thread
      scheduling order on slave.
      
      For now, remove these deadlocks by running the parallel slave in READ
      COMMITTED mode. And let InnoDB/XtraDB allow statement-based binlogging for the
      parallel slave in READ COMMITTED.
      
      We are also investigating a different solution long-term, which is based on
      relaxing the gap locks only between the transactions running in parallel for
      one slave, but not against possibly external transactions.
      b3529691
  3. 10 Feb, 2014 1 commit
    • Thirunarayanan B's avatar
      Bug #14049391 INNODB MISCALCULATES AUTO-INCREMENT AFTER DECREASING · 7acdf29c
      Thirunarayanan B authored
                              AUTO_INCREMENT_INCREMENT
      Problem:
      =======
      When auto_increment_increment system variable decreases,
      immediate next value of auto increment column is not affected.
      
      Solution:
      ========
      	Get the previous inserted value of auto increment column by
      subtracting the previous auto_increment_increment from next
      auto increment value. After that calculate the current autoinc value
      using newly changed auto_increment_increment variable.
      
      	Approved by Sunny [rb#4394]
      7acdf29c
  4. 02 Feb, 2014 1 commit
  5. 01 Feb, 2014 1 commit
  6. 24 Jan, 2014 1 commit
    • unknown's avatar
      BUG 18117322 - DEFINE INNODB_THREAD_SLEEP_DELAY MAX VALUE · 93609b57
      unknown authored
      The maximum value for innodb_thread_sleep_delay is 4294967295 (32-bit) or
      18446744073709551615 (64-bit) microseconds. This is way too big, since
      the max value of innodb_thread_sleep_delay is limited by
      innodb_adaptive_max_sleep_delay if that value is set to non-zero value
      (its default is 150,000).
      
      Solution
      The maximum value of innodb_thread_sleep_delay should be the same as
      the maximum value of innodb_adaptive_max_sleep_delay, which is 1000000.
      
      Approved by Jimmy, rb#4429
      93609b57
  7. 08 Jan, 2014 1 commit
    • Aditya A's avatar
      Bug#16287752 INNODB_DATA_FILE_PATH MINIMUM SIZE · dc1365d6
      Aditya A authored
                      IN DOCUMENTATION
      Problem 
      -------
      The documentation says that we support 'K' prefix 
      while specifiying size for innodb datafile in the
      server variable for innodb_data_file_path ,but the
      function srv_parse_megabytes() only handles only 
      'M' (megabytes) and 'G' (gigabytes) .
      
      Fix
      ---
      Modify srv_parse_megabytes() to handle Kilobytes. 
      
      Add in documentation that while specifying size 
      in KB it should be mentioned in multiples of 1024
      other wise they will be rounded off to nearest
      MB (megabyte) boundry .(eg if size mentioned
      as 2313KB will be considered as 2 MB ).
      
      [ Approved by Marko #rb 2387 ]
      dc1365d6
  8. 29 Dec, 2013 1 commit
    • Aditya A's avatar
      Bug#12762390 SHOW INNODB STATUS REPORTS NON-FK · 64b697ca
      Aditya A authored
                   ERRORS IN THE FK SECTION
      
      ANALYSIS
      --------
      
      Any error during the renaming of the table was 
      incorrectly logged in the dict_foreign_err_file
      and it showed up in foreign key section when
      we give the query "show engine innodb status".
      
      FIX
      ---
      Prevent renaming error from being logged in 
      dict_foreign_err_file section.  
      
      [Aprooved by marko #rb 2501 ]
      64b697ca
  9. 12 Dec, 2013 1 commit
  10. 13 Nov, 2013 1 commit
    • Sergei Golubchik's avatar
      MDEV-5248 Serious incompatibility and data corruption of DATETIME and DATE... · c155890a
      Sergei Golubchik authored
      MDEV-5248 Serious incompatibility and data corruption of DATETIME and DATE types due to get_innobase_type_from_mysql_type refactor combined with InnoDB Online DDL
      
      restore old innodb get_innobase_type_from_mysql_type() function,
      record all mysql_type->innodb_type mapping
      (as generated by mysql-5.6).
      add safety code to disable online alter when internal types don't match
      
      storage/innobase/dict/dict0stats.cc:
        revert to 5.6 state
      c155890a
  11. 31 Oct, 2013 1 commit
  12. 17 Oct, 2013 1 commit
    • Anil Toshniwal's avatar
      Bug#17513737 INTRODUCE CHECK TABLE...QUICK · 7c3d3f19
      Anil Toshniwal authored
      --Implemented CHECK TABLE...QUICK.
        Introduce CHECK TABLE...QUICK that would skip the btr_validate_index()
        and btr_search_validate() call, and count the no. of records in each index.
      
      Approved by Marko and Kevin. (rb#3567).
      
      7c3d3f19
  13. 14 Oct, 2013 1 commit
    • unknown's avatar
      MDEV-4506: Parallel replication: error handling. · 2842f6b5
      unknown authored
      Add an error code to the wait_for_commit facility.
      
      Now, when a transaction fails, it can signal the error to
      any subsequent transaction that is waiting for it to commit.
      The waiting transactions then receive the error code back from
      wait_for_prior_commit() and can handle the error appropriately.
      
      Also fix one race that could cause crash if @@slave_parallel_threads
      were changed several times quickly in succession.
      2842f6b5
  14. 09 Oct, 2013 1 commit
    • Praveenkumar Hulakund's avatar
      Bug#17474166 - EXECUTING STATEMENT LIKE 'SHOW ENGINE INNODB' · c66a037d
      Praveenkumar Hulakund authored
                     AND 'KILL SESSION' LEAD TO CRASH               
      
      Analysis:
      --------
      This situation occurs when the connection executes query 
      "show engine innodb status" and this connection is killed by
      executing statement "kill <con>" by another connection.
      
      In function "innodb_show_status", function "stat_print"
      is called to print the status but return value of function
      is not checked.  After killing connection, if write to 
      connection fails then error is returned and same is set
      in Diagnostic area. Since FALSE is returned from
      "innodb_show_status" now, assert to check no error
      is set in function "set_eof_status" (called from
      my_eof) is failing. 
      
      Fix:
      ----
      Changed code to check return value of function "stat_print"
      in "innodb_show_status".
      c66a037d
  15. 07 Oct, 2013 1 commit
  16. 26 Aug, 2013 1 commit
  17. 23 Aug, 2013 1 commit
  18. 14 Aug, 2013 1 commit
    • Sergey Vojtovich's avatar
      MDEV-4702 - Reduce usage of LOCK_open · b7f9c894
      Sergey Vojtovich authored
      Following variables do not require LOCK_open protection anymore:
      - table_def_cache (renamed to tdc_hash) is protected by rw-lock
        LOCK_tdc_hash;
      - table_def_shutdown_in_progress doesn't need LOCK_open protection;
      - last_table_id use atomics;
      - TABLE_SHARE::ref_count (renamed to TABLE_SHARE::tdc.ref_count)
        is protected by TABLE_SHARE::tdc.LOCK_table_share;
      - TABLE_SHARE::next, ::prev (renamed to tdc.next and tdc.prev),
        oldest_unused_share, end_of_unused_share are protected by
        LOCK_unused_shares;
      - TABLE_SHARE::m_flush_tickets (renamed to tdc.m_flush_tickets)
        is protected by TABLE_SHARE::tdc.LOCK_table_share;
      - refresh_version (renamed to tdc_version) use atomics.
      b7f9c894
  19. 12 Aug, 2013 1 commit
    • Sergei Golubchik's avatar
      MDEV-4786 merge 10.0-monty -> 10.0 · 847e0f15
      Sergei Golubchik authored
      remove unused HA_CAN_EXPORT
      (with the merge of "FLUSH TABLE <table_list> FOR EXPORT",
      this functionality should be added back, but differently -
      no table flag, handler::extra() returns an error instead)
      847e0f15
  20. 31 Jul, 2013 1 commit
  21. 25 Jul, 2013 1 commit
    • Annamalai Gurusami's avatar
      Bug #17076737 DUPLICATE CONSTRAINTS DISPLAYED WHEN NAME INCLUDES "_IBFK_" · a1ccfcf8
      Annamalai Gurusami authored
      Problem:
      
      When the user specified foreign key name contains "_ibfk_", InnoDB wrongly
      tries to rename it. 
      
      Solution:
      
      When a table is renamed, all its associated foreign keys will also be renamed,
      only if the foreign key names are automatically generated.  If the foreign key
      names are given by the user, even if it has _ibfk_ in it, it must not be
      renamed.
      
      rb#2935 approved by Jimmy, Krunal and Satya
      
      
      a1ccfcf8
  22. 10 Jul, 2013 2 commits
  23. 03 Jul, 2013 1 commit
    • Michael Widenius's avatar
      Fixed issues with partitions and create temporary table SELECT ... · a9d1d76e
      Michael Widenius authored
      Merged all ddl_logging code.
      Merged sql_partition.cc
      innodb_mysql_lock2.test and partition_cache.test now works.
      Changed interface to strconvert() to make it easier to use with not \0 terminated strings.
      
      sql/sql_partition.cc:
        Full merge with 5.6
      sql/sql_table.cc:
        Merged all ddl_logging code
      sql/strfunc.cc:
        Added from_length argument to strconvert() to make it possible to use without end terminated strings.
      sql/strfunc.h:
        Added from_length argument to strconvert() to make it possible to use without end terminated strings.
      a9d1d76e
  24. 02 Jul, 2013 1 commit
    • Michael Widenius's avatar
      mdl_sync now works. · 99aae21e
      Michael Widenius authored
      mysql-test/r/mdl_sync.result:
        Full merge with 5.6
      mysql-test/t/mdl_sync.test:
        Full merge with 5.6
      sql/debug_sync.cc:
        Full merge with 5.6
      sql/debug_sync.h:
        Full merge with 5.6
      sql/mdl.cc:
        Full merge with 5.6
      sql/sql_base.cc:
        Removed code not in 5.6 anymore
      99aae21e
  25. 26 Jun, 2013 1 commit
    • unknown's avatar
      MDEV-4506: Parallel replication. Intermediate commit. · 7e5dc4f0
      unknown authored
      Implement facility for the commit in one thread to wait for the commit of
      another to complete first. The wait is done in a way that does not hinder
      that a waiter and a waitee can group commit together with a single fsync()
      in both binlog and InnoDB. The wait is done efficiently with respect to
      locking.
      
      The patch was originally made to support TaoBao parallel replication with
      in-order commit; now it will be adapted to also be used for parallel
      replication of group-committed transactions.
      
      A waiter THD registers itself with a prior waitee THD. The waiter will then
      complete its commit at the earliest in the same group commit of the waitee
      (when using binlog). The wait can also be done explicitly by the waitee.
      7e5dc4f0
  26. 25 Jun, 2013 1 commit
  27. 19 Jun, 2013 1 commit
    • Aditya A's avatar
      Bug#11829813 UNUSED MUTEX COMMIT_THREADS_M · b3e74a07
      Aditya A authored
      Analysis
      --------
      The pthread_mutex commit_threads_m was initiliazed but never
      used. 
      
      Fix
      ---
      Removing the commit_threads_m mutex from the code base.
      
      [ Approved by Marko rb#2475]
      b3e74a07
  28. 18 Jun, 2013 1 commit
    • Vasil Dimov's avatar
      Fix Bug#16907783 5.5 STILL CRASHES IN DICT_UPDATE_STATISTICS WITH CONCURRENT · 9696ca9d
      Vasil Dimov authored
      DDL AND I_S QUERIES
      
      Skip partially created indexes (ones whose name starts with TEMP_INDEX_PREFIX)
      from stats gathering.
      
      Because InnoDB reports HA_INPLACE_ADD_INDEX_NO_WRITE to MySQL, the latter
      allows parallel execution of ha_innobase::add_index() and ha_innobase::info().
      
      Reviewed by:	Inaam (rb:2613)
      9696ca9d
  29. 15 Jun, 2013 1 commit
  30. 14 Jun, 2013 1 commit
    • unknown's avatar
      Bug#16914007-INNODB: CHECK TABLE SHOULD MARK AN INDEX AS CORRUPTED · e0c68b15
      unknown authored
      IF IT HAS A WRONG COUNT
      
      If CHECK TABLE finds that a secondary index contains the wrong
      number of entries, it used to report an error but not mark the
      index as corrupt. The error means that the index should be rebuilt,
      which can be done with ALTER TABLE DROP INDEX and ALTER TABLE ADD
      INDEX.  But just in case the DBA does not pay any attention to the
      output of CHECK TABLE, the secondary index should be marked as
      corrupted so that it is not used again.
      
      Approved by Inaam in RB:2607
      e0c68b15
  31. 15 May, 2013 1 commit
  32. 07 May, 2013 2 commits
    • Sujatha Sivakumar's avatar
      Bug#16513588:"PREPARE_COMMIT_MUTEX" IS NOT FREED DURING · e246b4a5
      Sujatha Sivakumar authored
      TRANSACTION ROLLBACK
      
      Problem:
      =======
      "prepare_commit_mutex" is acquired during "innobase_xa_prepare"
      and it is freed only in "innobase_commit". After prepare,
      if the commit operation fails the transaction is rolled back
      but the mutex is not released.
      
      Analysis:
      ========
      During transaction commit process transaction is prepared and
      the "prepare_commit_mutex" is acquired to preserve the order
      of commit. After prepare write to binlog is initiated.
      
      File: sql/handler.cc
            if (error || (is_real_trans && xid &&
      ----->             (error= !(cookie= tc_log->log_xid(thd, xid)))))
            {
              ha_rollback_trans(thd, all);
      
      In the above code "tc_log->log_xid" operation fails.
      
      When the write to binlog fails the transaction is rolled back
      with out freeing the mutex. A subsequent "INSERT" operation
      tries to acquire the same mutex during its commit process
      and the server aborts.
      
      Fix:
      ===
      "prepare_commit_mutex" is freed during "innobase_rollback".
      
      storage/innobase/handler/ha_innodb.cc:
        Added code to free "prepare_commit_mutex"
      e246b4a5
    • Murthy Narkedimilli's avatar
      Merging the changes from 5.1 branch to release branch. · be8f5a6b
      Murthy Narkedimilli authored
      Includes bug fixes for:
      Bug #16722314 FOREIGN KEY ID MODIFIED DURING EXPORT
      Bug #16754901 PARS_INFO_FREE NOT CALLED IN DICT_CREATE_ADD_FOREIGN_TO_DICTIONARY
      be8f5a6b
  33. 06 May, 2013 2 commits
    • Annamalai Gurusami's avatar
      Bug #16722314 FOREIGN KEY ID MODIFIED DURING EXPORT · 2c551d0e
      Annamalai Gurusami authored
      Bug #16754901 PARS_INFO_FREE NOT CALLED IN DICT_CREATE_ADD_FOREIGN_TO_DICTIONARY
      
      Merging the fix from mysql-5.5 to mysql-5.5.32-release.
      
      2c551d0e
    • Annamalai Gurusami's avatar
      Bug #16722314 FOREIGN KEY ID MODIFIED DURING EXPORT · bf7325bb
      Annamalai Gurusami authored
      Bug #16754901 PARS_INFO_FREE NOT CALLED IN DICT_CREATE_ADD_FOREIGN_TO_DICTIONARY
      
      Problem:
      
      There are two situations here.  The constraint name is explicitly
      given by the user and the constraint name is automatically generated
      by InnoDB.  In the case of generated constraint name, it is formed by
      adding table name as prefix.  The table names are stored internally in
      my_charset_filename.  In the case of constraint name explicitly given
      by the user, it is stored in UTF8 format itself.  So, in some
      situations the constraint name is in utf8 and in some situations it is
      in my_charset_filename format.  Hence this problem.
      
      Solution:
      
      Always store the foreign key constraint name in UTF-8 even when
      automatically generated.
      
      Bug #16754901 PARS_INFO_FREE NOT CALLED IN DICT_CREATE_ADD_FOREIGN_TO_DICTIONARY
      
      Problem:
      
      There was a memory leak in the function dict_create_add_foreign_to_dictionary().
      The allocated pars_info_t object is not freed in the error code path.
      
      Solution:
      
      Allocate the pars_info_t object after the error checking.
      
      rb#2368 in review
      
      bf7325bb
  34. 24 Apr, 2013 2 commits
  35. 19 Apr, 2013 1 commit