1. 20 Jun, 2018 3 commits
  2. 19 Jun, 2018 1 commit
  3. 12 Jun, 2018 1 commit
  4. 11 Jun, 2018 4 commits
  5. 10 Jun, 2018 9 commits
  6. 07 Jun, 2018 1 commit
    • Chris Calender's avatar
      MDEV-15789 - mysqlslap use incorrect table def · d9b159a2
      Chris Calender authored
      The bug arises when one uses --auto-generate-sql-guid-primary (and
      --auto-generate-sql-secondary-indexes) with mysqlslap and also have
      sql_mode=STRICT_TRANS_TABLE.
      
      When using this option, mysqlslap should create a column with varchar(36),
      but it appears to create it as a varchar(32) only. Then if one has
      sql_mode=STRICT_TRANS_TABLES, it throws an error, like:
      
        mysqlslap: Cannot run query INSERT INTO t1 VALUES (...)
        ERROR : Data too long for column 'id' at row 1
      
      Upstream bug report: BUG#80329.
      d9b159a2
  7. 06 Jun, 2018 1 commit
  8. 05 Jun, 2018 1 commit
  9. 02 Jun, 2018 1 commit
    • Varun Gupta's avatar
      MDEV-16225: wrong resultset from query with semijoin=on · 5fb2c586
      Varun Gupta authored
      For non-semi-join subquery optimization we do a cost based decision between
      Materialisation and IN -> EXIST transformation. The issue in this case is that for IN->EXIST transformation
      we run JOIN::reoptimize with the IN->EXISt conditions and we come up with a new query plan. But when we compare
      the cost with Materialization, we make the decision to chose Materialization so we need to restore the query plan
      for Materilization.
      The saving and restoring for keyuse array and join_tab keyuse is only done when we have atleast
      one element in the keyuse_array , we are now changing to do it even for 0 elements to main the generality.
      5fb2c586
  10. 23 May, 2018 1 commit
  11. 22 May, 2018 1 commit
  12. 18 May, 2018 1 commit
  13. 17 May, 2018 1 commit
  14. 16 May, 2018 1 commit
    • Sergey Vojtovich's avatar
      (almost) sane core handling in mtr · aa2e1ade
      Sergey Vojtovich authored
      Analyze core independently of max-save-datadir and max-save-core setting.
      
      Increment $num_saved_cores only if core was actually saved.
      
      "Move any core files from e.g. mysqltest" independently of
      max-save-datadir setting. Note: it may overwrite core from mysqld, which
      might not be desired (it did work this way even before).
      aa2e1ade
  15. 15 May, 2018 1 commit
  16. 10 May, 2018 1 commit
  17. 04 May, 2018 1 commit
  18. 30 Apr, 2018 2 commits
  19. 27 Apr, 2018 1 commit
  20. 25 Apr, 2018 2 commits
    • Igor Babaev's avatar
      MDEV-15035 Wrong results when calling a stored procedure · eb057dce
      Igor Babaev authored
      multiple times with different arguments.
      
      If the ON expression of an outer join is an OR formula with one
      of the disjunct being a constant formula then the expression
      cannot be null-rejected if the constant formula is true. Otherwise
      it can be null-rejected and if so the outer join can be converted
      into inner join. This optimization was added in the patch for
      mdev-4817. Yet the code had a defect: if the query was used in
      a stored procedure with parameters and the constant item contained
      some of them then the value of this constant item depended on the
      values of the parameters. With some parameters it may be true,
      for others not. The validity of conversion to inner join is checked
      only once and it happens only for the first call of procedure.
      So if the  parameters in the first call allowed the conversion it
      was done and next calls used the transformed query though there
      could be calls whose parameters made the conversion invalid.
      
      Fixed by cheking whether the constant disjunct in the ON expression
      originally contained an SP parameter. If so the expression is not
      considered as null-rejected. For this check a new item's attribute
      was intruduced: Item::with_param. It is calculated for each item
      by fix fields() functions.
      Also moved the call of optimize_constant_subqueries() in
      JOIN::optimize after the call of simplify_joins(). The reason
      for this is that after the optimization introduced by the patch
      for mdev-4817 simplify_joins() can use the results of execution
      of non-expensive constant subqueries and this is not valid.
      eb057dce
    • Oleksandr Byelkin's avatar
      MDEV-13699: Assertion `!new_field->field_name.str ||... · adaa891a
      Oleksandr Byelkin authored
      MDEV-13699: Assertion `!new_field->field_name.str || strlen(new_field->field_name.str) == new_field->field_name.length' failed in create_tmp_table on 2nd execution of PS with semijoin
      
      The problem was that SJ (semi-join) used secondary list (array) of subquery select list. The items there was prepared once then cleaned up (but not really freed from memory because it was made in statement memory).
      Original list was not prepared after first execution because select was removed by conversion to SJ.
      The solution is to use original list but prepare it first.
      adaa891a
  21. 23 Apr, 2018 1 commit
  22. 19 Apr, 2018 4 commits