1. 25 Jul, 2018 1 commit
    • Igor Babaev's avatar
      MDEV-16820 Lost 'Impossible where' from query with inexpensive subquery · d567f161
      Igor Babaev authored
      This patch fixes another problem introduced by the patch for mdev-4817.
      The latter changed Item_cond::fix_fields() in such a way that it could
      call the virtual method is_expensive(). With the first its call
      the method saves the result in Item::is_expensive_cache. For all next
      calls the method returns the result from this cache. So if the item
      once was determined as expensive the method always returns true.
      For subqueries it's not good, because non-optimized subqueries always
      is considered as expensive.
      It means that the cache should be invalidated after the call of
      optimize_constant_subqueries().
      d567f161
  2. 19 Jul, 2018 1 commit
    • Igor Babaev's avatar
      MDEV-16726 Assertion `tab->type == JT_REF || tab->type == JT_EQ_REF' failed · 9cea4ccf
      Igor Babaev authored
      Due to a legacy bug in the code of make_join_statistics() detecting
      so-called constant tables could miss some of them in rare queries
      that used RIGHT JOIN. As a result these queries had execution plans
      different from the execution plans of the equivalent queries with
      LEFT JOIN.
      Besides starting from 10.2 this could trigger an assertion failure.
      9cea4ccf
  3. 16 Jul, 2018 1 commit
  4. 11 Jul, 2018 1 commit
  5. 10 Jul, 2018 1 commit
  6. 30 Jun, 2018 1 commit
    • Igor Babaev's avatar
      MDEV-16603 Crash with set join_cache_level=4 · 90cb7212
      Igor Babaev authored
      When the definition of the index used for hash join was created
      in create_hj_key_for_table() it could cause memory overwrite
      due to a bug that led to an underestimation of the number of
      the index component.
      90cb7212
  7. 27 Jun, 2018 4 commits
    • Sergey Vojtovich's avatar
      MDEV-8540 - Crash on server shutdown since 10.0.16 · 9d41dd2f
      Sergey Vojtovich authored
      For the purpose of reporting an error to error log, shutdown thread was
      attempting to access current_thd->variables.lc_messages->errmsgs->errmsgs.
      Whereas current_thd was NULL.
      
      We should log errors according to global lc_messages setting instead of
      session setting.
      9d41dd2f
    • Michael Widenius's avatar
      Fixed MDEV-16512, crashing on re-execution of failing SP · 937c1931
      Michael Widenius authored
      MDEV-16512 Server crashes in find_field_in_table_ref on 2nd
      execution of SP referring to non-existing field
      
      Problem was in the natural join code that it changed TABLE_LIST and
      Item_fields but didn't restore changed things if things goes wrong
      and was not able to re-execute after failure.
      Some of the problems could have been avoided if we would have run
      fix_fields before doing natural join transformations.
      
      Fixed by marking functions complete AFTER they had executed, instead at
      start.
      I had also to change some tests that checked if Item_fields are usable.
      
      This doesn't fix all known problems, but at least avoids some crashes.
      What should be done in the near future is to mark the statement in the SP
      as 'not re-executable' and force a reparse of it on next execution.
      
      Reviewer: Sergei Petrunia <psergey@askmonty.org>
      937c1931
    • Michael Widenius's avatar
      faef2e6a
    • Michael Widenius's avatar
      1f6a89a8
  8. 26 Jun, 2018 1 commit
  9. 20 Jun, 2018 3 commits
  10. 19 Jun, 2018 1 commit
  11. 12 Jun, 2018 1 commit
  12. 11 Jun, 2018 4 commits
  13. 10 Jun, 2018 9 commits
  14. 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
  15. 06 Jun, 2018 1 commit
  16. 05 Jun, 2018 1 commit
  17. 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
  18. 23 May, 2018 1 commit
  19. 22 May, 2018 1 commit
  20. 18 May, 2018 1 commit
  21. 17 May, 2018 1 commit
  22. 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
  23. 15 May, 2018 1 commit
  24. 10 May, 2018 1 commit