1. 12 Apr, 2015 3 commits
  2. 31 Mar, 2015 1 commit
  3. 29 Mar, 2015 1 commit
  4. 23 Mar, 2015 1 commit
  5. 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
  6. 19 Mar, 2015 1 commit
  7. 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
  8. 12 Mar, 2015 1 commit
  9. 09 Mar, 2015 1 commit
  10. 06 Mar, 2015 4 commits
  11. 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
  12. 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
  13. 27 Feb, 2015 1 commit
  14. 23 Feb, 2015 1 commit
  15. 13 Feb, 2015 1 commit
  16. 12 Feb, 2015 1 commit
  17. 11 Feb, 2015 5 commits
  18. 10 Feb, 2015 2 commits
  19. 09 Feb, 2015 2 commits
  20. 11 Feb, 2015 1 commit
  21. 10 Feb, 2015 3 commits
  22. 09 Feb, 2015 1 commit
  23. 08 Feb, 2015 2 commits
  24. 06 Feb, 2015 1 commit
  25. 04 Feb, 2015 2 commits
    • Jan Lindström's avatar
      Fix test failure. · 5c6eb522
      Jan Lindström authored
      5c6eb522
    • Jan Lindström's avatar
      MDEV-7538: Wrong constraint (TINYINT or MEDIUMINT and INT) · 8cc97511
      Jan Lindström authored
      causes server crash
      
      Analysis: If wrong data types used on foreign constraint there
      was possibility that foreign->id is NULL when incorrect
      foreign constraint was removed from the dictionary cache.
      
      Fix: Add guard foreign->id != NULL before trying to lookup
      or remove the foreign constraint from dictionary cache.
      
      Tested using user database where problem was repeatable.
      8cc97511