1. 07 Apr, 2014 1 commit
  2. 10 Apr, 2014 4 commits
    • Elena Stepanova's avatar
      MDEV-6068 Upgrade removes all changes to 'mysql' database · a7962ea5
      Elena Stepanova authored
      10.0 variation of the problem was that system tables were altered
      during mysql_upgrade process using old (smaller) column lengths. 
      At the end the tables were altered again, so the structure was restored,
      but if there were long values before the upgrade, they were truncated.
      Fixed by using correct column length in alter statements.
      a7962ea5
    • Alexander Barkov's avatar
      Fixing compilation problem on AIX. · 5fffa449
      Alexander Barkov authored
      5fffa449
    • unknown's avatar
      MDEV-5401: Wrong result (missing row) on a 2nd execution of PS with... · 39afdcdd
      unknown authored
      MDEV-5401: Wrong result (missing row) on a 2nd execution of PS with exists_to_in=on, MERGE view or a SELECT SQ
      
      The problem was that the view substitute its fields (on prepare) with reverting the change after execution. After prepare on optimization exists2in convertion substituted arguments of '=' with constsnt '1', but then one of the arguments of '=' was reverted to the view field reference.This lead to incorrect WHERE condition on the second execution.
      
      To fix the problem we replace whole '=' with '1' permannently.
      39afdcdd
    • unknown's avatar
      MDEV-6040: MariaDB hangs if terminated quickly after start · 584c2d0a
      unknown authored
      We need to use mysql_cond_broadcast() rather than _signal for
      COND_thread_count, as there can be multiple waiters.
      
      Thanks to Pavel Ivanov for reporting both the problem and the
      solution.
      584c2d0a
  3. 09 Apr, 2014 1 commit
  4. 02 Apr, 2014 1 commit
  5. 01 Apr, 2014 1 commit
    • Sergey Petrunya's avatar
      MDEV-5992: EITS: Selectivity of non-indexed condition is counted twice in table's fanout · 26a3d567
      Sergey Petrunya authored
      MDEV-5984: EITS: Incorrect filtered% value for single-table select with range access
      - Fix calculate_cond_selectivity_for_table() to work correctly with range accesses 
        over multi-component keys:
        = First, take selectivity of all possible range scans into account. Remember which 
          fields were used bt the range scans.
        = Then, calculate selectivity produced by sargable predicates on fields. If a 
          field was used in a possible range access, assume its selectivity is already
          taken into account.
      - Fix table_cond_selectivity(): when quick select is used, selectivity of
        COND(table) is taken into account in matching_candidates_in_table(). In
        table_cond_selectivity() we should not apply it for the second time.
      26a3d567
  6. 31 Mar, 2014 2 commits
  7. 29 Mar, 2014 6 commits
  8. 28 Mar, 2014 8 commits
  9. 27 Mar, 2014 14 commits
  10. 26 Mar, 2014 2 commits