1. 24 Sep, 2019 1 commit
    • Alexander Barkov's avatar
      MDEV-20495 Assertion `precision > 0' failed in decimal_bin_size upon CREATE ..... · 67b0faa2
      Alexander Barkov authored
      MDEV-20495 Assertion `precision > 0' failed in decimal_bin_size upon CREATE .. SELECT with zerofilled decimal
      
      Also fixes:
      
      MDEV-20560 Assertion `precision > 0' failed in decimal_bin_size upon SELECT with MOD short unsigned decimal
      
      Changing the way how Item_func_mod calculates its max_length.
      It now uses decimal_precision(), decimal_scale() and unsigned_flag
      of its arguments, like all other Item_num_op descendants do.
      67b0faa2
  2. 20 Sep, 2019 4 commits
  3. 01 Sep, 2019 1 commit
  4. 21 Aug, 2019 1 commit
  5. 19 Aug, 2019 1 commit
    • Igor Babaev's avatar
      MDEV-20265 Unknown column in field list · e746f451
      Igor Babaev authored
      This patch corrects the fix of the patch for mdev-19421 that resolved
      the problem of parsing some embedded join expressions such as
        t1 join t2 left join t3 on t2.a=t3.a on t1.a=t2.a.
      Yet the patch contained a bug that prevented proper context analysis
      of the queries where such expressions were used together with comma
      separated table references in from clauses.
      e746f451
  6. 16 Aug, 2019 1 commit
  7. 12 Aug, 2019 2 commits
  8. 31 Jul, 2019 1 commit
  9. 26 Jul, 2019 1 commit
  10. 25 Jul, 2019 1 commit
  11. 24 Jul, 2019 6 commits
    • Nisha Gopalakrishnan's avatar
      BUG#28642318: POINT IN TIME RECOVERY USING MYSQLBINLOG BROKEN WITH TEMPORARY TABLE -> ERRORS · 2536c0b1
      Nisha Gopalakrishnan authored
      Analysis
      ========
      Point in time recovery using mysqlbinlog containing queries
      operating on temporary tables results in an error.
      
      While writing the query log event in the binary log, the
      thread id used for execution of DROP TABLE and DELETE commands
      were incorrect. The thread variable 'thread_specific_used'
      is used to determine whether a specific thread id is to used
      while executing the statements i.e using 'SET
      @@session.pseudo_thread_id'. This variable was not set
      correctly for DROP TABLE query and was never set for DELETE
      query. The thread id is important for temporary tables
      since the tables are session specific. DROP TABLE and DELETE
      queries executed using a wrong thread id resulted in errors
      while applying the queries generated by mysqlbinlog utility.
      
      Fix
      ===
      Set the 'thread_specific_used' THD variable for DROP TABLE and
      DELETE queries.
      
      ReviewBoard: 21833
      2536c0b1
    • Gleb Shchepa's avatar
      Bug #29419820: MEMORY LEAK IN MY_YYOVERFLOW() · 7473a71a
      Gleb Shchepa authored
      Note: this patch is for 5.6.
      
      Detected by ASAN.
      
      The patch fixes the cleanup of parser stack pointers.
      Reviewed-by: default avatarGuilhem Bichot <guilhem.bichot@oracle.com>
      7473a71a
    • Sergei Golubchik's avatar
      Bug#27167197 USING ? IN INSTALL PLUGIN QUERY ABORTS DEBUG, AND HANGS OPTIMIZED SERVER · 8ddb7e3e
      Sergei Golubchik authored
      check_valid_path() uses my_strcspn() that cannot handle invalid characters
      properly. This is fixed by a big refactoring in 10.2 (MDEV-6353).
      
      For 5.5, let's simply swap tests, because check_string_char_length()
      rejects invalid characters just fine.
      8ddb7e3e
    • Sergei Golubchik's avatar
      Bug#27302459: EMPTY VALUE IN MYSQL.PLUGIN TABLE CAUSES SERVER TO EXIT ON STARTUP · 5e8ab9b7
      Sergei Golubchik authored
      Description:- During server startup, the server exits if
      the 'mysql.plugin' system table has any rows with empty
      value for the field 'name' (plugin name).
      5e8ab9b7
    • Georgi Kodinov's avatar
      Bug #27312862: ASAN: HEAP-USE-AFTER-FREE: UPDATEXML RB#21666 RB#21666 · c5e96743
      Georgi Kodinov authored
      The xpath parsing function was using a local string buffer that was
      deallocated when going out of scope. However references to it are
      preserved in the XPATH parse tree. This was causing read-after-free.
      
      Fixed by making the xpath buffer a local variable inside the Item
      class for the relevant xpath function, thus being preserved for the
      duration of the query.
      c5e96743
    • Anushree Prakash B's avatar
      Bug#27259654 - ISSUES FOUND BY PVS-STUDIO STATIC ANALYZER · 9c6777c0
      Anushree Prakash B authored
      DESCRIPTION
      ===========
      PVS-Studio static code analyzer found several suspicious
      fragments of code across various files.
      
      i)   sizeof() is using the pointer
      ii)  memcpy() doesn't copy the whole string.
      iii) enumeration constant 'wkb_multilinestring' is used as
           a variable of a Boolean-type.
      iv) 'throw' keyword is missing from std::runtime_error()
      
      FIX
      ===
      i)   Use sizeof({actual object/data type})
      ii)  Use strncpy() and set last char as '\0'
      iii) N/A (Issue has already been fixed)
      iv)  Add 'throw' before the exception.
      
      RB: 21502
      9c6777c0
  12. 23 Jul, 2019 4 commits
    • Marko Mäkelä's avatar
      MDEV-8827: Fix the 32-bit build · 9d93f9da
      Marko Mäkelä authored
      Follow-up to 07ba5560:
      Use the correct 64-bit type name ulonglong instead of ulint,
      like in mysql/mysql-server@4e0100d86b1b46be0107ebd46a98a0c2dbb0fab4
      9d93f9da
    • Rahul Malik's avatar
      Bug#15851528 DUPLICATE KEY ERROR ON AUTO-INC PK WITH MIXED AUTO_INCREMENT_INCREMENT CLIENTS · 739f5239
      Rahul Malik authored
      Problem: Clients running different values for auto_increment_increment
      and doing concurrent inserts leads to "Duplicate key error" in one of them.
      
      Analysis:
      When auto_increment_increment value is reduced in a session,
      InnoDB uses last auto_increment_increment value
      to recalculate the autoinc value.
      In case, some other session has inserted a value
      with different auto_increment_increment, InnoDB recalculate
      autoinc values based on current session previous auto_increment_increment
      instead of considering the auto_increment_increment used for last insert
      across all session
      
      Fix:
      revert 7acdf29c
      a.k.a. 7c12a9e5
      as it causing the bug.
      
      Reviewed By:
      Bin <bin.x.su@oracle.com>
      Kevin <kevin.lewis@oracle.com>
      RB#21777
      
      Note: In MariaDB Server, earlier changes in
      ae5bc059
      for MDEV-533 require that the original test in
      mysql/mysql-server@1ccd472d63a042d3237a55f5827239164219ef7e
      be adjusted for MariaDB.
      
      Also, ef47b625 (MDEV-8827)
      had to be reverted after the upstream fix had been backported.
      739f5239
    • Marko Mäkelä's avatar
      Revert "MDEV-8827 Duplicate key with auto increment" · 7153e155
      Marko Mäkelä authored
      This reverts commit ef47b625.
      The parent commit 07ba5560
      which is a backport of
      mysql/mysql-server@1198267c331b045b9cad26be72b1a5b4f8930a79
      fixes the issue differently.
      7153e155
    • Thirunarayanan Balathandayuthapani's avatar
      Bug #20989615 INNODB AUTO_INCREMENT PRODUCES SAME VALUE TWICE · 07ba5560
      Thirunarayanan Balathandayuthapani authored
      Problem:
      =======
      Autoincrement value gives duplicate values because of the following reasons.
      
      (1) In InnoDB handler function, current autoincrement value is not changed
      based on newly set auto_increment_increment or auto_increment_offset variable.
      
      (2) Handler function does the rounding logic and changes the current
      autoincrement value and InnoDB doesn't aware of the change in current
      autoincrement value.
      
      Solution:
      ========
      Fix the problem(1), InnoDB always respect the auto_increment_increment
      and auto_increment_offset value in case of current autoincrement value.
      By fixing the problem (2), handler layer won't change any current
      autoincrement value.
      Reviewed-by: default avatarJimmy Yang <jimmy.yang@oracle.com>
      RB: 13748
      07ba5560
  13. 21 Jul, 2019 1 commit
  14. 19 Jul, 2019 1 commit
  15. 18 Jul, 2019 1 commit
  16. 12 Jul, 2019 1 commit
  17. 11 Jul, 2019 1 commit
    • Igor Babaev's avatar
      MDEV-19421 Basic 3-way join queries are not parsed. · 8540fa83
      Igor Babaev authored
      The parser returned a syntax error message for the queries with join
      expressions like this t1 JOIN t2 [LEFT | RIGHT] JOIN t3 ON ... ON ... when
      the second operand of the outer JOIN operation with ON clause was another
      join expression with ON clause. In this expression the JOIN operator is
      right-associative, i.e. expression has to be parsed as the expression
      t1 JOIN (t2 [LEFT | RIGHT] JOIN t3 ON ... ) ON ...
      Such join expressions are hard to parse because the outer JOIN is
      left-associative if there is no ON clause for the first outer JOIN operator.
      The patch implements the solution when the JOIN operator is always parsed
      as right-associative and builds first the right-associative tree. If it
      happens that there is no corresponding ON clause for this operator the
      tree is converted to left-associative.
      
      The idea of the solution was taken from the patch by Martin Hansson
      "WL#8083: Fixed the join_table rule" from MySQL-8.0 code line.
      As the grammar rules related to join expressions in MySQL-8.0 and
      MariaDB-5.5+ are quite different MariaDB solution could not borrow
      any code from the MySQL-8.0 solution.
      8540fa83
  18. 08 Jul, 2019 1 commit
    • Mostafa Hussein's avatar
      use -f with pgrep · 8997f20f
      Mostafa Hussein authored
      pgrep will not be able to get th pid using the full path which is $libexec/mysqld unless -f is being used
      8997f20f
  19. 05 Jul, 2019 1 commit
  20. 01 Jul, 2019 2 commits
    • Vicențiu Ciorbaru's avatar
      Extra comment to mysql_install_db · ecd8f448
      Vicențiu Ciorbaru authored
      Explain why it makes sense to not consider builddir == srcdir directly,
      for cases when we do out-of-source builds.
      ecd8f448
    • Daniel Black's avatar
      mysql_install_db: assume builddir is dirname0 · d890c45b
      Daniel Black authored
      The assumption in the original commit for --builddir (648d3ced),
      was to assume that without a --builddir, and when --srcdir
      is specified, that the builddir is the same as the srcdir.
      
      The problem is that this assumption does not hold for out-of-source
      builds and we can figure out the builddir by looking for where
      mysql_install_db script is.
      
      As mysql_install_db is in the builddir, we use dirname0 as the builddir after
      checking that my_print_defaults is also located from dirname0, otherwise
      default to old behavior.
      d890c45b
  21. 25 Jun, 2019 1 commit
  22. 22 Jun, 2019 1 commit
    • Igor Babaev's avatar
      MDEV-19778 Wrong Result on Left Outer Join with Subquery right on true · 645191aa
      Igor Babaev authored
                 and WHERE filter afterwards
      
      This patch complements the patch fixing the bug MDEV-6892. The latter
      properly handled queries that used mergeable views returning constant
      columns as inner tables of outer joins and whose where clause contained
      predicates referring to these columns if the predicates of happened not
      to be equality predicates. Otherwise the server still could return wrong
      result sets for such queries. Besides the fix for MDEV-6892 prevented
      some possible conversions of outer joins to inner joins for such queries.
      
      This patch corrected the function check_simple_equality() to handle
      properly conjunctive equalities of the where clause that refer to the
      constant columns of mergeable views used as inner tables of an outer join.
      The patch also changed the code of Item_direct_view_ref::not_null_tables().
      This change allowed to take into account predicates containing references
      to constant columns of mergeable views when converting outer joins into
      inner joins.
      645191aa
  23. 19 Jun, 2019 1 commit
  24. 17 Jun, 2019 1 commit
    • Igor Babaev's avatar
      MDEV-19790 Wrong result for query with outer join and IS NOT TRUE predicate · 167da05f
      Igor Babaev authored
                 in where clause
      
      The classes Item_func_isnottrue and Item_func_isnotfalse inherited the
      implementation of the eval_not_null_tables method from the Item_func
      class. As a result the not_null_tables_cache was set incorrectly for
      the objects of these classes. It led to improper conversion of outer
      joins to inner joins when the where clause of the processed query
      contained IS NOT TRUE or IS NOT FALSE predicates. The coverted query
      in many cases produced a wrong result set.
      167da05f
  25. 12 Jun, 2019 1 commit
    • Eugene Kosov's avatar
      MDEV-13631 Make use of clang-format · 039b8782
      Eugene Kosov authored
      Explicitly mention every options in .clang-format to protect us from possible
      future changes.
      
      Remove separate InnoDB style.
      
      Change style to look more like this script:
      for x in $@
      do
       indent -kr -bl -bli0 -l79 -i2 -nut -c48 -dj -cp0 $x
       sed -ri -e 's/ = /= /g'\
               -e '/switch.*\)$/{N;s/\n[ ]+/ /}' $x
      done
      
      Significant different is that 'switch' and '{' are put on different lines
      because it's impossible in clang-format to set formatting rules just for
      'switch' statement.
      039b8782
  26. 11 Jun, 2019 2 commits