1. 12 Jul, 2017 1 commit
    • Sergei Golubchik's avatar
      MDEV-7339 Server crashes in Item_func_trig_cond::val_int · c5975eae
      Sergei Golubchik authored
      Item_in_subselect::pushed_cond_guards[] array is allocated only when
      left_expr->maybe_null. And it is used (for row expressions) when
      left_expr->element_index(i)->maybe_null.
      
      For left_expr being a multi-column subquery, its maybe_null is
      always false when the subquery doesn't use tables (see
      Item_singlerow_subselect::fix_length_and_dec()
      and subselect_single_select_engine::fix_length_and_dec()),
      otherwise it's always true.
      
      But row elements can be NULL regardless, so let's always allocate
      pushed_cond_guards for multi-column subqueries, no matter whether
      its maybe_null was forced to true or false.
      c5975eae
  2. 06 Jul, 2017 1 commit
  3. 05 Jul, 2017 1 commit
  4. 04 Jul, 2017 1 commit
  5. 03 Jul, 2017 6 commits
  6. 29 Jun, 2017 1 commit
  7. 27 Jun, 2017 2 commits
  8. 19 Jun, 2017 1 commit
  9. 18 Jun, 2017 3 commits
  10. 14 Jun, 2017 4 commits
  11. 08 Jun, 2017 1 commit
    • Igor Babaev's avatar
      Fixed the bug mdev-12855. · b850fc66
      Igor Babaev authored
      This is actually a legacy bug:
      SQL_SELECT::test_quick_select() was called
      with SQL_SELECT::head not set.
      It looks like that this problem can be
      reproduced only on queries with ORDER BY
      that use IN predicates converted to semi-joins.
      b850fc66
  12. 07 Jun, 2017 2 commits
    • Igor Babaev's avatar
      Fixed the bug mdev-12963. · 151f4e9b
      Igor Babaev authored
      This patch corrects the fix for bug mdev-7599.
      When the min/max optimization of the function
      opt_sum_query() optimizes away all tables of
      a subquery it should not ever be rolled back.
      151f4e9b
    • Igor Babaev's avatar
      Fixed the bug mdev-12838. · c258ca24
      Igor Babaev authored
      If the optimizer chose an execution plan where
      a semi-join nest were materialized and the
      result of materialization was scanned to access
      other tables by ref access it could build a key
      over columns of the tables from the nest that
      were actually inaccessible.
      The patch performs a proper check whether a key
      that uses columns of the tables from a materialized
      semi-join nest can be employed to access outer tables.
      c258ca24
  13. 29 May, 2017 1 commit
  14. 23 May, 2017 1 commit
  15. 19 May, 2017 1 commit
  16. 18 May, 2017 2 commits
    • Oleksandr Byelkin's avatar
      Make IF clear. · 4a846e01
      Oleksandr Byelkin authored
      4a846e01
    • Sachin Setiya's avatar
      MDEV-11092 Assertion `!writer.checksum_len || writer.remains == 0' failed · b5cdf014
      Sachin Setiya authored
      Problem:-
      This crash happens because logged stmt is quite big and while writing
      Annotate_rows_log_event it throws EFBIG error  but we ignore this error
      and do not call cache_data->set_incident().
      
      Solution:-
      When we normally write Binlog_log_event we check for error EFBIG, but we did
      do this for Annotate_rows_log_event. We check for this error and call
      cache_data->set_incident() accordingly.
      
      # Conflicts:
      #	sql/log.cc
      b5cdf014
  17. 17 May, 2017 2 commits
    • Igor Babaev's avatar
      Fixed the bug mdev-12812. · efb9f261
      Igor Babaev authored
      This is another correction of the patch for bug mdev-12670.
      If a derived table is merged into a select with STRAIGHT_JOIN
      modifier all IN subquery predicates contained in the
      specification of the derived table cannot be subject to
      conversion to semi-joins.
      efb9f261
    • Igor Babaev's avatar
      Fixed the bug mdev-12817/mdev-12820. · 7e971631
      Igor Babaev authored
      This patch is a correction of the patch for bug mdev-12670.
      With the current code handling semi-joins the following must
      be taken into account.
      Conversion of an IN subquery predicate into semi-join
      has to be blocked if the predicate occurs:
      (a) in the ON expression of an outer join
      (b) in the ON expression of an inner join embedded directly
          or indirectly in the inner nest of an outer join.
      The patch for mdev-12670 blocked conversion to semi-joins only
      in the case (a), but not in the case (b). This patch blocks
      the conversion in both cases.
      7e971631
  18. 16 May, 2017 1 commit
    • Igor Babaev's avatar
      Fixed the bug mdev-7791. · 934b8312
      Igor Babaev authored
      When an IN subquery predicate was converted to a semi-join that were
      materialized and the result of the materialization happened to be
      the last in the execution plan then any conjunctive condition with RAND()
      turned out to be lost.
      
      Fixed by attaching this condition to the last top base table.
      934b8312
  19. 15 May, 2017 2 commits
    • Sergei Golubchik's avatar
      MDEV-12799 Buffer overflow · 2e1428c0
      Sergei Golubchik authored
      with a specially corrupted master.info one can
      get an invalid heartbeat_period that will
      trigger a heap overflow.
      2e1428c0
    • Igor Babaev's avatar
      Fixed the bug mdev-7599. · e0352fb0
      Igor Babaev authored
      At some conditions the function opt_sum_query() can apply MIN/MAX
      optimizations to to Item_sum objects of a select These optimizations
      becomes invalid if this select is the subquery of an IN subquery
      predicate that is converted to a EXISTS subquery. Thus in this case
      the MIX/MAX optimizations that have been applied in opt_sum_query()
      must be rolled back.
      This bug appeared in 5.3 when the code for the cost base choice between
      materialization and in-to-exists transformation of non-correlated
      IN subqueries was introduced. Before this code in-to-exists
      transformations were always performed before the call of opt_sum_query().
      e0352fb0
  20. 12 May, 2017 1 commit
  21. 09 May, 2017 1 commit
    • Igor Babaev's avatar
      Fixed the bugs mdev-12670 and mdev-12675. · 6b97fe06
      Igor Babaev authored
      The code that blocked conversion of a IN subselect pedicate to a semi-join
      if it occurred in the ON expression of an outer join did not do it correctly.
      As a result, the conversion was blocked for IN subselect predicates
      encountered in ON expressions of INNER joins or in WHERE conditions
      of mergeable views / derived tables. This patch fixes this problem.
      6b97fe06
  22. 05 May, 2017 1 commit
    • Igor Babaev's avatar
      Fixed the bug mdev-12673. · 15f9931f
      Igor Babaev authored
      This patch corrects the fix for the bug mdev-10693.
      It is critical for the function get_best_combination() not to call
      create_ref_for_key() for constant tables.
      This bug could manifest itself only in multi-table subqueries where
      one of the tables is accessed by a constant primary key.
      15f9931f
  23. 02 May, 2017 1 commit
  24. 30 Apr, 2017 1 commit
    • Daniel Black's avatar
      mysqld_safe_help - remove warning · dbe2c3c5
      Daniel Black authored
      /home/travis/build/MariaDB/server/extra/mysqld_safe_helper.c:62:21: warning: too many arguments in call to 'do_usage'
          do_usage(argv[0]);
          ~~~~~~~~        ^
      1 warning generated.
      dbe2c3c5
  25. 24 Apr, 2017 1 commit
    • Igor Babaev's avatar
      Fixed the bug mdev-10693. · 2e7ba70a
      Igor Babaev authored
      The code that chooses between materialization of a non-correlated
      IN subquery and its transformation into an EXISTS correlated
      subquery assumes that the execution plan for the outer select
      has been already built. However it was not always so if subqueries
      occurred in the expressions used for ref access to tables of
      the outer select. A call of the function create_ref_for_key() in
      get_best_combination() could trigger a premature execution of
      the above mentioned code when the execution plan structures for
      the outer select were not fully built. This could cause a crash
      of the server.
      
      The fix postpones the calls of create_ref_for_key() until the
      structures for the execution plan is fully built.
      2e7ba70a