1. 27 Apr, 2015 5 commits
  2. 26 Apr, 2015 1 commit
    • Sergei Golubchik's avatar
      MDEV-7126 replication slave - deadlock in terminate_slave_thread with stop... · f8320210
      Sergei Golubchik authored
      MDEV-7126 replication slave - deadlock in terminate_slave_thread with stop slave and show variables of replication filters and show global status
      
      Three-way deadlock:
      
        T1: SHOW GLOBAL STATUS
            -> acquire LOCK_status
        T2: STOP SLAVE
            -> acquire LOCK_active_mi
            -> terminate_slave_thread()
            -> -> cond_timedwait for handle_slave_sql to stop
        T3: sql slave thread (same applies to io thread)
            -> handle_slave_sql(), when exiting
            -> -> THD::add_status_to_global()
            -> -> -> wait for LOCK_status...
        T1: SHOW GLOBAL STATUS
            -> for "Slave_heartbeat_period" status variable
            -> -> show_heartbeat_period()
            -> -> -> wait for LOCK_active_mi
      
      cherry-pick from 5.6:
      
        commit fc8b395898f40387b3468122bd0dae31e29a6fde
        Author: Venkatesh Duggirala <venkatesh.duggirala@oracle.com>
        Date:   Wed Jun 12 21:41:05 2013 +0530
      
          BUG#16904035-SHOW STATUS - EXCESSIVE LOCKING ON LOCK_ACTIVE_MI AND
          ACTIVE_MI->RLI->DATA_LOCK
      
          Problem: Excessive locking on lock_active_mi and rli->data_lock
          while executing any `show status like 'X'` command.
      
          Analysis: SHOW_FUNCs for Slave_running, Slave_retried_transactions,
          Slave_heartbeat_period, Slave_received_heartbeats,
          Slave_last_heartbeat are acquiring lock_active_mi and rli->data_lock
          to show their variable value. It is ok to show stale data while showing
          the status variables i.e., even if they miss one update, it will
          not cause any great trouble.
      
          Fix: Remove the locks from the above mentioned SHOW_FUNC functions.
      
      Add a test case
      f8320210
  3. 24 Apr, 2015 2 commits
  4. 23 Apr, 2015 2 commits
  5. 22 Apr, 2015 1 commit
  6. 21 Apr, 2015 1 commit
  7. 20 Apr, 2015 1 commit
  8. 19 Apr, 2015 1 commit
  9. 15 Apr, 2015 4 commits
  10. 11 Apr, 2015 1 commit
  11. 31 Mar, 2015 1 commit
  12. 29 Mar, 2015 1 commit
  13. 23 Mar, 2015 1 commit
  14. 20 Mar, 2015 1 commit
    • Vicențiu Ciorbaru's avatar
      MDEV-7682 Incorrect use of SPATIAL KEY for query plan · 9253064c
      Vicențiu Ciorbaru authored
      If the spatial key is used within an equality comparison, the comparison
      does not produce relevant results generally as identical geometry can be
      stored differently. Still, we want to support the operation. In order
      to allow a hash join plan, we must define a key_length for Field_geom.
      9253064c
  15. 19 Mar, 2015 1 commit
  16. 17 Mar, 2015 1 commit
    • Sergei Petrunia's avatar
      MDEV-7474: Semi-Join's DuplicateWeedout strategy skipped ... · c020d362
      Sergei Petrunia authored
      JOIN::cur_dups_producing_tables was not maintained correctly in
      the cases of greedy optimization (search_depth < n_tables).
      
      Moved it to POSITION structure where it will be maintained automatically.
      
      Removed POSITION::prefix_dups_producing_tables since its value can now
      be calculated.
      c020d362
  17. 12 Mar, 2015 1 commit
  18. 09 Mar, 2015 1 commit
  19. 06 Mar, 2015 4 commits
  20. 05 Mar, 2015 1 commit
    • Jan Lindström's avatar
      MDEV-7578 :Slave is ~10x slower to execute set of statements compared to master when using RBR · f66fbe8c
      Jan Lindström authored
      Analysis: On master when executing (single/multi) row INSERTs/REPLACEs
      InnoDB fallback to old style autoinc locks (table locks)
      only if another transaction has already acquired the AUTOINC lock.
      Instead on slave as we are executing log_events and sql_command
      is not correctly set, InnoDB does not use new style autoinc
      locks when it could.
      
      Fix: Use new style autoinc locks also when
      thd_sql_command(user_thd) == SQLCOM_END i.e. this is RBR event.
      f66fbe8c
  21. 28 Feb, 2015 1 commit
    • Vicențiu Ciorbaru's avatar
      MDEV-6838: Using too big key for internal temp tables · 45b6edb1
      Vicențiu Ciorbaru authored
      This bug manifests due to wrong computation and evaluation of
      keyinfo->key_length. The issues were:
      * Using table->file->max_key_length() as an absolute value that must not be
        reached for a key, while it represents the maximum number of bytes
        possible for a table key.
      * Incorrectly computing the keyinfo->key_length size during
        KEY_PART_INFO creation. The metadata information regarding the key
        such the field length (for strings) was added twice.
      45b6edb1
  22. 27 Feb, 2015 1 commit
  23. 23 Feb, 2015 1 commit
  24. 13 Feb, 2015 1 commit
  25. 12 Feb, 2015 1 commit
  26. 11 Feb, 2015 3 commits