1. 29 Oct, 2020 1 commit
  2. 28 Oct, 2020 5 commits
  3. 27 Oct, 2020 6 commits
    • Eugene Kosov's avatar
      MDEV-23991 dict_table_stats_lock() has unnecessarily long scope · afc9d00c
      Eugene Kosov authored
      Patch removes dict_index_t::stats_latch. Table/index statistics now
      protected with dict_sys->mutex. That way statistics computation can
      happen in parallel in several threads and dict_sys->mutex will be locked
      only for a short period of time.
      
      This patch is a joint work with Marko Mäkelä
      
      dict_index_t::lock: make mutable which allows to pass const pointer
      when only lock is touched in an object
      
      btr_height_get()
      btr_get_size(): make index argument const for better type safety
      
      btr_estimate_number_of_different_key_vals(): now returns computed values
      instead of setting fields in dict_index_t directly
      
      remove everything related to dict_index_t::stats_latch
      
      dict_stats_index_set_n_diff(): now returns computed values instead
      of setting fields in dict_index_t directly
      
      dict_stats_analyze_index():  now returns computed values instead
      of setting fields in dict_index_t directly
      
      Reviewed by: Marko Mäkelä
      afc9d00c
    • Anel Husakovic's avatar
      MDEV-24018: SIGSEGV in Item_func_nextval::update_table on SELECT SETVAL · e183aec1
      Anel Husakovic authored
      Reviewed-by: wlad@mariadb.com
      e183aec1
    • Marko Mäkelä's avatar
      MDEV-16952 Introduce SET GLOBAL innodb_max_purge_lag_wait · 42e1815a
      Marko Mäkelä authored
      Let us introduce a dummy variable innodb_max_purge_lag_wait
      for waiting that the InnoDB history list length is below
      the user-specified limit. Specifically,
      
      SET GLOBAL innodb_max_purge_lag_wait=0;
      
      should wait for all history to be purged. This could be useful
      when upgrading from an older version to MariaDB 10.3 or later,
      to avoid hitting MDEV-15912.
      
      Note: the history cannot be purged if there exist transactions
      that may see old versions.
      
      Reviewed by: Vladislav Vaintroub
      42e1815a
    • Alexey Botchkov's avatar
      MDEV-22524 SIGABRT in safe_mutex_unlock with · 8761571a
      Alexey Botchkov authored
      session_track_system_variables and max_relay_log_size.
      
      lock LOCK_global_system_variables around the get_one_variable() call
      in the Session_sysvars_tracker::store_variable().
      8761571a
    • Thirunarayanan Balathandayuthapani's avatar
      MDEV-23693 Failing assertion: my_atomic_load32_explicit(&lock->lock_word,... · bc540b87
      Thirunarayanan Balathandayuthapani authored
      MDEV-23693 Failing assertion: my_atomic_load32_explicit(&lock->lock_word, MY_MEMORY_ORDER_RELAXED) == X_LOCK_DECR
      
      InnoDB frees the block lock during buffer pool shrinking when other
      thread is yet to release the block lock.  While shrinking the
      buffer pool, InnoDB allows the page to be freed unless it is buffer
      fixed. In some cases, InnoDB releases the latch after unfixing the
      block.
      
      Fix:
      ====
      - InnoDB should unfix the block after releases the latch.
      
      - Add more assertion to check buffer fix while accessing the page.
      
      - Introduced block_hint structure to store buf_block_t pointer
      and allow accessing the buf_block_t pointer only by passing a
      functor. It returns original buf_block_t* pointer if it is valid
      or nullptr if the pointer become stale.
      
      - Replace buf_block_is_uncompressed() with
      buf_pool_t::is_block_pointer()
      
      This change is motivated by a change in mysql-5.7.32:
      mysql/mysql-server@46e60de444a8fbd876cc6778a7e64a1d3426a48d
      Bug #31036301 ASSERTION FAILURE: SYNC0RW.IC:429:LOCK->LOCK_WORD
      bc540b87
    • mkaruza's avatar
      MDEV-22707: galera got stuck after flush tables · 6a614d69
      mkaruza authored
      Deadlock is possible between applier thread and local committing thread with active FLUSH TABLE.
      Applier thread should skip table share checks and locks when opening table.
      Reviewed-by: default avatarJan Lindström <jan.lindstrom@mariadb.com>
      6a614d69
  4. 26 Oct, 2020 3 commits
    • Sachin Agarwal's avatar
      Bug #31228694 FTS QUERY WITH LIMIT HIT AN ASSERT · 1ff8588c
      Sachin Agarwal authored
      Problem:
      1. The server terminates abnormally when phrase search doesn't
      filter out doc_ids correctly. This problem has been fixed in bug
      2. Wrong query result: It's a regression from the bug #22709692 fix.
      This fix optimize full-text search query with limit clause.
      when FTS expression involves only union operation, we fetch only
      number of doc_ids specified with the limit clause.
      Fulltext phrase search is not an union operation and we consider
      phrase search with plugin parser a union operation.
      In phrase search with limit clause, we fetch limited doc_ids for
      each token and if any of the selected doc_id does not contain all
      tokens in correct order then we do not include that row_id in the
      result set.
      Therefore phrase search gets fewer number of rows than the qualified
      rows exist in the table.
      
      Fix:
      Added a condition that phrase search with plugin parser is not a
      union operation.
      
      RB: 24925
      Reviewed by : Annamalai Gurusami <annamalai.gurusami@oracle.com>
      
      This is a cherry-pick of
      mysql/mysql-server@5549920b7a33ef33034461d973a9ecb17ce49799
      without a test case, because the test case depends on an n-gram
      tokenizer that will be missing from MariaDB until MDEV-10267 is added.
      1ff8588c
    • Sachin Agarwal's avatar
      Bug #30933728 INNODB FTS PHRASE SEARCH HIT AN ASSERT · e391417f
      Sachin Agarwal authored
      Problem:
      In Full-text phrase search, we filter out row that do not contain
      all the tokens in the phrase.
      If we do not filter out doc_id that doesn't appear in all the
      token's doc_id lists then we hit an assert.
      
      Fix:
      if any of the token has last doc_id equal to ith doc_id of the first
      token doc_id list then filter out rest of the higher doc_ids.
      
      RB: 24909
      Reviewed by : Annamalai Gurusami <annamalai.gurusami@oracle.com>
      
      This is a cherry-pick of
      mysql/mysql-server@5aa075277dfe84a17a0331c57a6fe9b91dafb4cf
      but without a test case, because the test case depends on an n-gram
      tokenizer that will be missing from MariaDB until MDEV-10267 is added.
      e391417f
    • Oleksandr Byelkin's avatar
  5. 25 Oct, 2020 3 commits
    • Sergei Golubchik's avatar
      remove disable_abort_on_error from precedence.test · 2fdc5036
      Sergei Golubchik authored
      was left over from testing
      2fdc5036
    • Thirunarayanan Balathandayuthapani's avatar
      MDEV-23370 innodb_fts.innodb_fts_misc failed in buildbot, server crashed in... · 3ba8f619
      Thirunarayanan Balathandayuthapani authored
      MDEV-23370 innodb_fts.innodb_fts_misc failed in buildbot, server crashed in dict_table_autoinc_destroy
      
      This issue is caused by MDEV-22456 ad6171b9. Fix involves the backported version of 10.4 patch
      MDEV-22778 5f2628d1 and few parts of
      MDEV-17441 (e9a5f288).
      
      dict_table_t::stats_latch_created: Removed
      
      dict_table_t::stats_latch: make value member and always lock it for
      simplicity even for stats cloned table.
      
      zip_pad_info_t::mutex_created: Removed
      
      zip_pad_info_t::mutex: make member value instead of pointer
      
      os0once.h: Removed
      
      dict_table_remove_from_cache_low(): Ensure that fts_free() is always
      called, even if dict_mem_table_free() is deferred until
      btr_search_lazy_free().
      
      InnoDB would always zip_pad_info_t::mutex and
      dict_table_t::autoinc_mutex, even for tables are not in
      ROW_FORMAT=COMPRESSED nor include any AUTO_INCREMENT column.
      3ba8f619
    • Marko Mäkelä's avatar
      MDEV-23720 Change innodb_log_optimize_ddl=OFF by default · 987df9b3
      Marko Mäkelä authored
      MariaDB 10.2.2 inherited from MySQL 5.7 a perceived optimization
      of ALTER TABLE, which skips the writing of redo log records.
      In MDEV-16809 we introduced a parameter that allows the redo log to
      be written, so that Mariabackup would not be impacted, but we kept
      the MySQL 5.7 behaviour enabled by default (innodb_log_optimize_ddl=ON).
      
      As noted in MDEV-19747 (Deprecate and ignore innodb_log_optimize_ddl,
      implemented in MariaDB 10.5.1), omitting the redo log writes can
      actually reduce performance, because we will have to wait for the data
      pages to be written out. When the redo log file is configured to be
      large enough, it actually can be much faster to write the redo log and
      avoid the extra page flushing.
      
      When the redo log is omitted (innodb_log_optimize_ddl=ON), also
      Mariabackup may have to perform a lot of extra work, to re-copy the
      entire data file if it is possible that any log was omitted during
      the backup.
      
      Starting with MariaDB 10.5.1, the parameter innodb_log_optimize_ddl
      is deprecated and ignored. We hereby deprecate (but will not ignore)
      the parameter in earlier versions as well.
      987df9b3
  6. 24 Oct, 2020 2 commits
  7. 23 Oct, 2020 20 commits