1. 02 Jul, 2020 2 commits
  2. 01 Jul, 2020 2 commits
  3. 30 Jun, 2020 1 commit
  4. 29 Jun, 2020 1 commit
  5. 27 Jun, 2020 1 commit
    • Varun Gupta's avatar
      MDEV-17606: Query returns wrong results (while using CHARACTER SET utf8) · 37cb7a00
      Varun Gupta authored
      The issue here was that the left expr and right expr of the ANY subquery
      had different character sets, so we were converting the left expr to utf8 character set.
      So when this conversion was happening we were actually converting the item inside the cache,
      it looked like <cache>(convert(t1.l1 using utf8)), which is incorrect.
      To fix this problem we are going to store the reference of the left expr and convert that
      to utf8 character set, it would look like convert(<cache>(`test`.`t1`.`l1`) using utf8)
      37cb7a00
  6. 25 Jun, 2020 4 commits
    • Sujatha's avatar
      MDEV-22806: MSAN reports use-of-uninitialized-value for rpl_parallel_conflicts.test · 3bc89395
      Sujatha authored
      Problem:
      ========
      Relay_log_info::flush reports following MSAN issue.
      ==17820==WARNING: MemorySanitizer: use-of-uninitialized-value is reported
      #5  0x00005584f0981441 in my_write (Filedes=22,
      Buffer=0x72500003e818 "5\n./slave-relay-bin.000003\n21385\n
      master-bin.000001\n21643\n0\n", '\245' <repeats 141 times>..., Count=118,
      MyFlags=532) at /home/sujatha/bug_repo/test-10.5-msan/mysys/my_write.c:49
      
      Analysis:
      =========
      In parallel replication at the end of each statement execution the worker execution
      status is updated in 'relay-log.info' file. When two workers try to flush
      the status at the same time, since the write to cache is not serialized both
      workers write to the same address simultaneously and increment the
      length twice. Because of this the length of buffer is more than actual data.
      When flush code tries to read the buffer beyond valid data length MSAN
      reports uninitialized values error.
      
      Fix:
      ===
      Serialize the relay log flush operation using "rli->data_lock".
      3bc89395
    • Julius Goryavsky's avatar
    • Vladislav Vaintroub's avatar
      MDEV-22950 followup · 7ee6a3ae
      Vladislav Vaintroub authored
      Deadlock in DbugParse, on Linux.
      
      In 10.1, DBUG recursive mutex was improperly implemented.
      CODE_STATE::locked counter was never updated.
      
      Copy the code around LockMutex/UnlockMutex from 10.2
      7ee6a3ae
    • Sujatha's avatar
      MDEV-22706: Assertion `!current' failed in PROFILING::start_new_query · f1838434
      Sujatha authored
      Analysis:
      ========
      When "Profiling" is enabled, server collects the resource usage of each
      statement that gets executed in current session. Profiling doesn't support
      nested statements. In order to ensure this behavior when profiling is enabled
      for a statement, there should not be any other active query which is being
      profiled. This active query information is stored in 'current' variable. When
      a nested query arrives it finds 'current' being not NULL and server aborts.
      
      When 'init_connect' and 'init_slave' system variables are set they contain a
      set of statements to be executed. "execute_init_command" is the function call
      which invokes "dispatch_command" for each statement provided in
      'init_connect', 'init_slave' system variables. "execute_init_command" invokes
      "start_new_query" and it passes the statement list to "dispatch_command". This
      "dispatch_command" intern invokes "start_new_query" which leads to nesting of
      queries. Hence '!current' assert is triggered.
      
      Fix:
      ===
      Remove profiling from "execute_init_command" as it will be done within
      "dispatch_command" execution.
      f1838434
  7. 24 Jun, 2020 2 commits
  8. 23 Jun, 2020 2 commits
  9. 19 Jun, 2020 3 commits
  10. 16 Jun, 2020 1 commit
    • Sujatha's avatar
      MDEV-20428: "Start binlog_dump" message doesn't indicate GTID position · bf74f7f9
      Sujatha authored
      Problem:
      =======
      The "Start binlog_dump" message hasn't been updated to include the slave's
      requested GTID position:
      
      20:05:05 139836760311552 [Note] Start binlog_dump to slave_server(2), pos(, 4)
      
      For diagnostic purposes, it would be helpful if the GTID position were
      included.
      
      Fix:
      ===
      Imporve "Start binlog_dump" print message to include "using_gtid" and
      "GTID position" requested by slave.
      
      Ex:
      [Note] Start binlog_dump to slave_server(2), pos(, 4), using_gtid(1),
        gtid('1-1-201,2-2-100')
      
      [Note] Start binlog_dump to slave_server(3), pos('mariadb-bin.004142',
        507988273), using_gtid(0), gtid('')
      bf74f7f9
  11. 15 Jun, 2020 1 commit
  12. 11 Jun, 2020 1 commit
    • Alexander Barkov's avatar
      MDEV-22755 CREATE USER leads to indirect SIGABRT in __stack_chk_fail () from... · de20091f
      Alexander Barkov authored
      MDEV-22755 CREATE USER leads to indirect SIGABRT in __stack_chk_fail () from fill_schema_user_privileges + *** stack smashing detected *** (on optimized builds)
      
      The code erroneously used buff[100] in a fiew places to make
      a GRANTEE value in the form:
        'user'@'host'
      
      Fix:
      - Fixing the code to use (USER_HOST_BUFF_SIZE + 6) instead of 100.
      - Adding a DBUG_ASSERT to make sure the buffer is enough
      - Wrapping the code into a class Grantee_str, to reuse it easier in 4 places.
      de20091f
  13. 10 Jun, 2020 3 commits
  14. 09 Jun, 2020 1 commit
    • rucha174's avatar
      MDEV-22830: SQL_CALC_FOUND_ROWS not working properly for single SELECT for DUAL · 44339123
      rucha174 authored
      In case of SELECT without tables which returns either 0 or 1 rows,
      JOIN::exec_inner() did not check if the flag representing SQL_CALC_FOUND_ROWS
      is set or not and send_records was direclty assigned 0. So SELECT FOUND_ROWS()
      was giving 0 in the output. Now it checks if the flag is set, if it is set
      send_record=1 else 0. 1 is the number of rows that could have been sent
      to the client if the SELECT query had SQL_CALC_FOUND_ROWS.
      It is 0 when no rows were sent because the SELECT query did not have
      SQL_CALC_FOUND_ROWS.
      44339123
  15. 08 Jun, 2020 2 commits
  16. 06 Jun, 2020 1 commit
    • Varun Gupta's avatar
      MDEV-22728: SIGFPE in Unique::get_cost_calc_buff_size from... · d218d1aa
      Varun Gupta authored
      MDEV-22728: SIGFPE in Unique::get_cost_calc_buff_size from prepare_search_best_index_intersect on optimized builds
      
      For low sort_buffer_size, in the cost calculation of using the Unique object the elements in the tree were evaluated to 0, make sure to have atleast 1 element in the Unique tree.
      
      Also for the function Unique::get allocate memory for atleast MERGEBUFF2+1 keys.
      d218d1aa
  17. 04 Jun, 2020 1 commit
    • Varun Gupta's avatar
      MDEV-22715: SIGSEGV in radixsort_for_str_ptr and in native_compare/my_qsort2 (optimized builds) · f30ff10c
      Varun Gupta authored
      For DECIMAL[(M[,D])] datatype max_sort_length was not being honoured which was leading to buffer
      overflow while making the sort key. The fix to this problem would be to create sort keys for decimals
      with atmost max_sort_key bytes
      
      Important:
      The minimum value of max_sort_length has been raised to 8 (previously was 4),
      so fixed size datatypes like DOUBLE and BIGINIT are not truncated for
      lower values of max_sort_length.
      f30ff10c
  18. 03 Jun, 2020 3 commits
  19. 02 Jun, 2020 1 commit
  20. 29 May, 2020 5 commits
    • Sergey Vojtovich's avatar
      Attempt fixing mroonga gcc 8 build failure · 49854811
      Sergey Vojtovich authored
      Part of MDEV-19061 - table_share used for reading statistical tables is
                           not protected
      49854811
    • Sergey Vojtovich's avatar
      Thread safe histograms loading · c2798784
      Sergey Vojtovich authored
      Previously multiple threads were allowed to load histograms concurrently.
      There were no known problems caused by this. But given amount of data
      races in this code, it'd happen sooner or later.
      
      To avoid scalability bottleneck, histograms loading is protected by
      per-TABLE_SHARE atomic variable.
      
      Whenever histograms were loaded by preceding statement (hot-path), a
      scalable load-acquire check is performed.
      
      Whenever histograms have to be loaded anew, mutual exclusion for loaders
      is established by atomic variable. If histograms are being loaded
      concurrently, statement waits until load is completed.
      
      - Table_statistics::total_hist_size moved to TABLE_STATISTICS_CB: only
        meaningful within TABLE_SHARE (not used for collected stats).
      - TABLE_STATISTICS_CB::histograms_can_be_read and
        TABLE_STATISTICS_CB::histograms_are_read are replaced with a tri state
        atomic variable.
      - Simplified away alloc_histograms_for_table_share().
      
      Note: there's still likely a data race if a thread attempts accessing
      histograms data after it failed to load it (because of concurrent load).
      It was there previously and goes out of the scope of this effort. One way
      of fixing it could be reviving TABLE::histograms_are_read and adding
      appropriate checks whenever it is needed.
      
      Part of MDEV-19061 - table_share used for reading statistical tables is
                           not protected
      c2798784
    • Sergey Vojtovich's avatar
      Thread safe statistics loading · 609a0d3d
      Sergey Vojtovich authored
      Previously multiple threads were allowed to load statistics concurrently.
      There were no known problems caused by this. But given amount of data
      races in this code, it'd happen sooner or later.
      
      To avoid scalability bottleneck, statistics loading is protected by
      per-TABLE_SHARE atomic variable.
      
      Whenever statistics were loaded by preceding statement (hot-path), a
      scalable load-acquire check is performed.
      
      Whenever statistics have to be loaded anew, mutual exclusion for loaders
      is established by atomic variable. If statistics are being loaded
      concurrently, statement waits until load is completed.
      
      TABLE_STATISTICS_CB::stats_can_be_read and
      TABLE_STATISTICS_CB::stats_is_read are replaced with a tri state atomic
      variable.
      
      Part of MDEV-19061 - table_share used for reading statistical tables is
                           not protected
      609a0d3d
    • Sergey Vojtovich's avatar
      Simplified away statistics_for_tables_is_needed() · 1055a7f4
      Sergey Vojtovich authored
      Removed redundant loops, integrated logics into the caller instead.
      Unified condition in read_statistics_for_tables(), less
      "table_share != NULL" checks, no more potential "table_share == NULL"
      dereferencing.
      
      Part of MDEV-19061 - table_share used for reading statistical tables is
                           not protected
      1055a7f4
    • Alexander Barkov's avatar
      MDEV-22744 *SAN: sql/item_xmlfunc.cc:791:43: runtime error: downcast of... · a2932e86
      Alexander Barkov authored
      MDEV-22744 *SAN: sql/item_xmlfunc.cc:791:43: runtime error: downcast of address ... which does not point to an object of type 'Item_func' note: object is of type 'Item_bool' (on optimized builds)
      
      In Item_nodeset_func_predicate::val_nodeset, args[1] is not necessarily
      an Item_func descendant. It can be Item_bool.
      
      Removing a wrong cast. It was not really needed anyway.
      a2932e86
  21. 28 May, 2020 2 commits
    • Anel Husakovic's avatar
      fix pre-definition for embedded server for find_user_or_anon() · a1b3bebe
      Anel Husakovic authored
      Pre-definitions are allowed for non-embedded.
      Failur catched with:
      ```
      cmake ../../10.1 -DCMAKE_BUILD_TYPE=Debug -DCMAKE_CXX_COMPILER=g++-9
      -DCMAKE_C_COMPILER=gcc-9 -DWITH_EMBEDDED_SERVER=ON -DCMAKE_BUILD_TYPE=Debug
      -DPLUGIN_{ARCHIVE,TOKUDB,MROONGA,OQGRAPH,ROCKSDB,PERFSCHEMA,SPIDER,SPHINX}=N
      -DMYSQL_MAINTAINER_MODE=ON -DNOT_FOR_DISTRIBUTION=ON
      ```
      Alternative fix would be
      ```
      --- a/sql/sql_acl.cc
      +++ b/sql/sql_acl.cc
      @@ -201,8 +201,10 @@ LEX_STRING current_user= { C_STRING_WITH_LEN("*current_user") };
       LEX_STRING current_role= { C_STRING_WITH_LEN("*current_role") };
       LEX_STRING current_user_and_current_role= { C_STRING_WITH_LEN("*current_user_and_current_role") };
      
      +#ifndef EMBEDDED_LIBRARY
       class ACL_USER;
       static ACL_USER *find_user_or_anon(const char *host, const char *user, const char *ip);
      +#endif
      ```
      a1b3bebe
    • Anel Husakovic's avatar
      MDEV-22312: Bad error message for SET DEFAULT ROLE when user account is not granted the role · 957cb7b7
      Anel Husakovic authored
      - `SET DEFAULT ROLE xxx [FOR yyy]` should say:
        "User yyy has not been granted a role xxx" if:
          - The current user (not the user `yyy` in the FOR clause) can see the
          role xxx. It can see the role if:
            * role exists in `mysql.roles_mappings` (traverse the graph),
            * If the current user has read access on `mysql.user` table - in
          that case, it can see all roles, granted or not.
          - Otherwise it should be "Invalid role specification".
      
      In other words, it should not be possible to use `SET DEFAULT ROLE` to discover whether a specific role exist or not.
      957cb7b7