1. 06 Jun, 2019 3 commits
  2. 05 Jun, 2019 2 commits
  3. 04 Jun, 2019 1 commit
    • Varun Gupta's avatar
      MDEV-18015: Assertion `global_status_var.global_memory_used == 0' failed when... · 7906bee6
      Varun Gupta authored
      MDEV-18015: Assertion `global_status_var.global_memory_used == 0' failed when using UDF , window functions and views
      
      Adding destructor for Group_bound_tracker to free Cached_item_str.
      The Cached_item for window functions are allocated on THD:mem_root
      but the Cached_item_str has value of type string which is allocated on
      the heap, so we need to call free() for it
      7906bee6
  4. 03 Jun, 2019 8 commits
  5. 31 May, 2019 2 commits
    • Vlad Lesin's avatar
      MDEV-18207: ASAN heap-use-after-free in _ma_get_status upon concurrent operations with sequence · c9b49a4b
      Vlad Lesin authored
      The issue is that two MARIA_HA instances shares the same MARIA_STATUS_INFO
      object during UNION execution, so the second MARIA_HA instance state pointer
      MARIA_HA::state points to the MARIA_HA::state_save of the first MARIA instance.
      
      This happens in
      thr_multi_lock(...) {
      ...
      	for (first_lock=data, pos= data+1 ; pos < end ; pos++)
      	{
      ...
      		if (pos[0]->lock == pos[-1]->lock && pos[0]->lock->copy_status)
      			(pos[0]->lock->copy_status)((*pos)->status_param,
      																	(*first_lock)->status_param);
      ...
      	}
      ...
      }
      
      Usually the state is restored from ha_maria::external_lock(...):
      
      \#0  _ma_update_status (param=0x6290000e6270) at ./storage/maria/ma_state.c:309
      \#1  0x00005555577ccb15 in _ma_update_status_with_lock (info=0x6290000e6270) at ./storage/maria/ma_state.c:361
      \#2  0x00005555577c7dcc in maria_lock_database (info=0x6290000e6270, lock_type=2) at ./storage/maria/ma_locking.c:66
      \#3  0x0000555557802ccd in ha_maria::external_lock (this=0x61d0001b1308, thd=0x62a000048270, lock_type=2) at ./storage/maria/ha_maria.cc:2727
      
      But _ma_update_status() does not take into account the case when
      MARIA_HA::status points to the MARIA_HA::state_save of the other MARIA_HA
      instance.
      
      The fix is to restore MARIA_HA::state in ha_maria::external_lock() after
      maria_lock_database() call for transactional tables.
      c9b49a4b
    • Marko Mäkelä's avatar
      Define page_id_t in buf0types.h · 9d142a89
      Marko Mäkelä authored
      9d142a89
  6. 30 May, 2019 2 commits
  7. 29 May, 2019 4 commits
  8. 28 May, 2019 11 commits
    • Marko Mäkelä's avatar
      MDEV-19587 innodb_force_recovery=5 crash on DROP SCHEMA · 1ca75ae1
      Marko Mäkelä authored
      At higher levels of innodb_force_recovery, the InnoDB transaction
      subsystem will not be set up at all.
      
      At slightly lower levels, recovered transactions will not be rolled back,
      and DDL operations could hang due to locks being held at all.
      
      Let us consistently refuse all writes if the predicate
      high_level_read_only holds. We failed to refuse DROP TABLE
      and DROP DATABASE. (Refusing DROP TABLE is a partial backport
      from MDEV-19570 in the 10.5 branch.)
      1ca75ae1
    • Thirunarayanan Balathandayuthapani's avatar
      MDEV-19602 Replace mysql_version check with frm_version for virtual columns inside InnoDB · 96d9f033
      Thirunarayanan Balathandayuthapani authored
      - Replace mysql_version check with omit_virtual_cols() in
      ha_innobase::check_if_supported_inplace_alter().
      96d9f033
    • Marko Mäkelä's avatar
      Merge 10.1 into 10.2 · d59e15bd
      Marko Mäkelä authored
      d59e15bd
    • Thirunarayanan Balathandayuthapani's avatar
      MDEV-19509 InnoDB skips the tablespace in rotation list · 88157247
      Thirunarayanan Balathandayuthapani authored
      - If one of the encryption threads already started the initialization
      of the tablespace then don't remove the other uninitialized tablespace
      from the rotation list.
      
      - If there is a change in innodb_encrypt_tables then
      don't remove the processed tablespace from rotation list.
      88157247
    • Marko Mäkelä's avatar
      MDEV-19614: Fix innodb_plugin on Windows · 8358c6f0
      Marko Mäkelä authored
      LOCK_global_system_variables: Declare with MYSQL_PLUGIN_IMPORT
      8358c6f0
    • Thirunarayanan Balathandayuthapani's avatar
      MDEV-19541 InnoDB crashes when trying to recover a corrupted page · 79b46ab2
      Thirunarayanan Balathandayuthapani authored
      - Don't apply redo log for the corrupted page when innodb_force_recovery > 0.
      - Allow the table to be dropped when index root page is
      corrupted when innodb_force_recovery > 0.
      79b46ab2
    • Marko Mäkelä's avatar
      Merge 5.5 into 10.1 · bf8fe324
      Marko Mäkelä authored
      bf8fe324
    • Marko Mäkelä's avatar
      MDEV-19614 SET GLOBAL innodb_ deadlock due to LOCK_global_system_variables · 626f2a1c
      Marko Mäkelä authored
      The update callback functions for several settable global InnoDB variables
      are acquiring InnoDB latches while holding LOCK_global_system_variables.
      
      On the other hand, some InnoDB code is invoking THDVAR() while holding
      InnoDB latches. An example of this is thd_lock_wait_timeout() that is
      called by lock_rec_enqueue_waiting(). In some cases, the
      intern_sys_var_ptr() that is invoked by THDVAR() may acquire
      LOCK_global_system_variables, via sync_dynamic_session_variables().
      
      In lock_rec_enqueue_waiting(), we really must be holding some InnoDB
      latch while invoking THDVAR(). This implies that
      LOCK_global_system_variables must conceptually reside below any InnoDB
      latch in the latching order. That in turns implies that the various
      update callback functions must release LOCK_global_system_variables
      before acquiring any InnoDB mutexes or rw-locks, and reacquire
      LOCK_global_system_variables later. The validate functions are being
      invoked while not holding LOCK_global_system_variables and thus they
      do not need any changes.
      
      The following statements are affected by this:
      
      SET GLOBAL innodb_adaptive_hash_index = …;
      SET GLOBAL innodb_cmp_per_index_enabled = 1;
      SET GLOBAL innodb_old_blocks_pct = …;
      SET GLOBAL innodb_fil_make_page_dirty_debug = …; -- debug builds only
      SET GLOBAL innodb_buffer_pool_evict = uncompressed; -- debug builds only
      SET GLOBAL innodb_purge_run_now = 1; -- debug builds only
      SET GLOBAL innodb_purge_stop_now = 1; -- debug builds only
      SET GLOBAL innodb_log_checkpoint_now = 1; -- debug builds only
      SET GLOBAL innodb_buf_flush_list_now = 1; -- debug builds only
      SET GLOBAL innodb_buffer_pool_dump_now = 1;
      SET GLOBAL innodb_buffer_pool_load_now = 1;
      SET GLOBAL innodb_buffer_pool_load_abort = 1;
      SET GLOBAL innodb_status_output = …;
      SET GLOBAL innodb_status_output_locks = …;
      SET GLOBAL innodb_encryption_threads = …;
      SET GLOBAL innodb_encryption_rotate_key_age = …;
      SET GLOBAL innodb_encryption_rotation_iops = …;
      SET GLOBAL innodb_encrypt_tables = …;
      SET GLOBAL innodb_disallow_writes = …;
      
      buf_LRU_old_ratio_update(): Correct the return type.
      626f2a1c
    • Marko Mäkelä's avatar
      MDEV-6812: Remove the wrapper my_log2f() · 242a28c3
      Marko Mäkelä authored
      242a28c3
    • Marko Mäkelä's avatar
      Mention the sample IPv4 address 10.0.0.1 · 661289f4
      Marko Mäkelä authored
      661289f4
    • Igor Babaev's avatar
      MDEV-18479 Assertion `join->best_read < double(1.79769313486231570815e+308L)' · 0955462d
      Igor Babaev authored
      or server crashes in JOIN::fix_all_splittings_in_plan after EXPLAIN
      
      This patch resolves the problem of overflowing when performing
      calculations to estimate the cost of an evaluated query execution plan.
      The overflowing in a non-debug build could cause different kind of
      problems uncluding crashes of the server.
      0955462d
  9. 27 May, 2019 2 commits
  10. 24 May, 2019 4 commits
    • Andrei Elkin's avatar
      MDEV-17948 Assertion `thd_killed(thd) || !m_active_tranxs .. · aaf53ea0
      Andrei Elkin authored
      Simulation of a big-sized event in rpl.rpl_semi_sync_skip_repl did not clean
      up after itself so screw the last binlog event offset which could jump
      backwards.
      The test is refined to rotate a binlog file with simulation and use the next
      one for logics of the test incl master-slave synchonization.
      aaf53ea0
    • Vlad Lesin's avatar
      MDEV-14192: mariabackup.incremental_backup failed in buildbot with Failing... · bff9b802
      Vlad Lesin authored
      MDEV-14192: mariabackup.incremental_backup failed in buildbot with Failing assertion: byte_offset % OS_FILE_LOG_BLOCK_SIZE == 0
      
      In some cases it's possible that InnoDB redo log file header is re-written so,
      that checkpoint lsn and checkpoint lsn offset are updated, but checkpoint
      number stays the same. The fix is to re-read redo log header if at least one
      of those three parametes is changed at backup start.
      
      Repeat the logic of log_group_checkpoint() on choosing InnoDB checkpoint info
      field on backup start. This does not influence backup correctness, but
      simplifies bugs analysis.
      bff9b802
    • Marko Mäkelä's avatar
      Declare INFORMATION_SCHEMA.INNODB_SYS_VIRTUAL stable · c8740407
      Marko Mäkelä authored
      The INFORMATION_SCHEMA plugin INNODB_SYS_VIRTUAL, which was introduced
      in MariaDB 10.2.2 along with the dictionary table SYS_VIRTUAL,
      is similar to other, much older and already stable plugins that
      provide access to InnoDB dictionary tables.
      c8740407
    • Igor Babaev's avatar
      MDEV-19258 RIGHT JOIN hangs in MariaDB · e57bb1f7
      Igor Babaev authored
      This patch corrects the patch for the bug 10006. The latter incorrectly
      calculates the attribute TABLE_LIST::dep_tables for inner tables
      of outer joins that are to be converted into inner joins.
      As a result after the patch some valid join orders were not evaluated
      and the optimizer could choose an execution plan that was far from
      being optimal.
      e57bb1f7
  11. 22 May, 2019 1 commit