1. 22 Jul, 2020 1 commit
    • Varun Gupta's avatar
      MDEV-19232: Floating point precision / value comparison problem · 62d73df6
      Varun Gupta authored
      The issue occurs when the subquery_cache is enabled.
      When there is a cache miss the division was leading to a value with scale 9.
      In the case of cache hit the value returned was of scale 9 and due to the different
      values for the scales the where condition evaluated to FALSE, hence the output
      was incomplete.
      
      To fix this problem we need to round up the decimal to the limit mentioned in
      Item::decimals. This would make sure the values are compared with the same
      scale.
      62d73df6
  2. 20 Jul, 2020 3 commits
    • Marko Mäkelä's avatar
      MDEV-23190 InnoDB data file extension is not crash-safe · 57ec42bc
      Marko Mäkelä authored
      When InnoDB is extending a data file, it is updating the FSP_SIZE
      field in the first page of the data file.
      
      In commit 8451e090 (MDEV-11556)
      we removed a work-around for this bug and made recovery stricter,
      by making it track changes to FSP_SIZE via redo log records, and
      extend the data files before any changes are being applied to them.
      
      It turns out that the function fsp_fill_free_list() is not crash-safe
      with respect to this when it is initializing the change buffer bitmap
      page (page 1, or generally, N*innodb_page_size+1). It uses a separate
      mini-transaction that is committed (and will be written to the redo
      log file) before the mini-transaction that actually extended the data
      file. Hence, recovery can observe a reference to a page that is
      beyond the current end of the data file.
      
      fsp_fill_free_list(): Initialize the change buffer bitmap page in
      the same mini-transaction.
      
      The rest of the changes are fixing a bug that the use of the separate
      mini-transaction was attempting to work around. Namely, we must ensure
      that no other thread will access the change buffer bitmap page before
      our mini-transaction has been committed and all page latches have been
      released.
      
      That is, for read-ahead as well as neighbour flushing, we must avoid
      accessing pages that might not yet be durably part of the tablespace.
      
      fil_space_t::committed_size: The size of the tablespace
      as persisted by mtr_commit().
      
      fil_space_t::max_page_number_for_io(): Limit the highest page
      number for I/O batches to committed_size.
      
      MTR_MEMO_SPACE_X_LOCK: Replaces MTR_MEMO_X_LOCK for fil_space_t::latch.
      
      mtr_x_space_lock(): Replaces mtr_x_lock() for fil_space_t::latch.
      
      mtr_memo_slot_release_func(): When releasing MTR_MEMO_SPACE_X_LOCK,
      copy space->size to space->committed_size. In this way, read-ahead
      or flushing will never be invoked on pages that do not yet exist
      according to FSP_SIZE.
      57ec42bc
    • Marko Mäkelä's avatar
      98e2c17e
    • Marko Mäkelä's avatar
      14543afd
  3. 18 Jul, 2020 1 commit
  4. 16 Jul, 2020 2 commits
  5. 15 Jul, 2020 2 commits
  6. 14 Jul, 2020 6 commits
  7. 13 Jul, 2020 1 commit
  8. 07 Jul, 2020 1 commit
  9. 06 Jul, 2020 4 commits
    • Rucha Deodhar's avatar
      MDEV-22654: Assertion `!is_set() || (m_status == DA_OK_BULK && is_bulk_op())' · a5366255
      Rucha Deodhar authored
      failed in Diagnostics_area::set_ok_status on FUNCTION replace
      
      When there is REPLACE in the statement, sp_drop_routine_internal() returns
      0 (SP_OK) on success which is then assigned to ret. So ret becomes false
      and the error state is lost. The expression inside DBUG_ASSERT()
      evaluates to false and thus the assertion failure.
      a5366255
    • Vladislav Vaintroub's avatar
      MDEV-23098 mariadb-upgrade-service.exe does not work on WAMPServer · cad9a9b1
      Vladislav Vaintroub authored
      While trying to detect datadir, take into account that one can use
      Windows service name as section name in options file, for Windows service.
      
      The historical obscurity is being used by WAMP installations.
      cad9a9b1
    • Varun Gupta's avatar
      MDEV-22390: Assertion `m_next_rec_ptr >= m_rawmem' failed in... · 6163af93
      Varun Gupta authored
      MDEV-22390: Assertion `m_next_rec_ptr >= m_rawmem' failed in Filesort_buffer::spaceleft | SIGSEGV in __memmove_avx_unaligned_erms from my_b_write
      
      Make sure that the sort_buffer that is allocated has atleast space for MERGEBUFF2 keys.
      The issue here was that the record length is quite high and sort buffer size is very small,
      due to which we end up with zero number of keys in the sort buffer. The Sort_param::max_keys_per_buffer
      was zero in such a case, due to which we were flushing empty sort_buffer to the disk.
      6163af93
    • Daniel Black's avatar
      MDEV-22173: socket accept - test for failure · 3efdac20
      Daniel Black authored
      accept might return an error, including SOCKET_EAGAIN/
      SOCKET_EINTR. The caller, usually handle_connections_sockets
      can these however and invalid file descriptor isn't something
      to call fcntl on.
      
      Thanks to Etienne Guesnet (ATOS) for diagnosis,
      sample patch description and testing.
      3efdac20
  10. 02 Jul, 2020 2 commits
  11. 01 Jul, 2020 2 commits
  12. 30 Jun, 2020 1 commit
  13. 29 Jun, 2020 1 commit
  14. 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
  15. 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
  16. 24 Jun, 2020 2 commits
  17. 23 Jun, 2020 2 commits
  18. 19 Jun, 2020 3 commits
  19. 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