1. 14 May, 2020 7 commits
  2. 13 May, 2020 2 commits
  3. 12 May, 2020 3 commits
    • Vlad Lesin's avatar
      MDEV-22398: mariabackup.innodb_xa_rollback fails on repeat · 218d20ff
      Vlad Lesin authored
      Flush LSN to system tablespace on innodb shutdown if XA is rolled back by
      mariabackup.
      218d20ff
    • Marko Mäkelä's avatar
      Cleanup: Remove InnoDB wrappers of thd_charset(), thd_query_safe() · 0e6a5786
      Marko Mäkelä authored
      innobase_get_charset(), innobase_get_stmt_safe(): Remove.
      It is more efficient and readable to invoke thd_charset()
      and thd_query_safe() directly, without a non-inlined wrapper function.
      0e6a5786
    • Marko Mäkelä's avatar
      MDEV-22529 thd_query_safe() isn’t, causing InnoDB to hang · a2560b00
      Marko Mäkelä authored
      The function thd_query_safe() is used in the implementation of the
      following INFORMATION_SCHEMA views:
      
          information_schema.innodb_trx
          information_schema.innodb_locks
          information_schema.innodb_lock_waits
          information_schema.rocksdb_trx
      
      The implementation of the InnoDB views is in trx_i_s_common_fill_table().
      This function invokes trx_i_s_possibly_fetch_data_into_cache(),
      which will acquire lock_sys->mutex and trx_sys->mutex in order to
      protect the set of active transactions and explicit locks.
      While holding those mutexes, it will traverse the collection of
      InnoDB transactions. For each transaction, thd_query_safe() will be
      invoked.
      
      When called via trx_i_s_common_fill_table(), thd_query_safe()
      is acquiring THD::LOCK_thd_data while holding the InnoDB locks.
      This will cause a deadlock with THD::awake() (such as executing
      KILL QUERY), because THD::awake() could invoke lock_trx_handle_wait(),
      which attempts to acquire lock_sys->mutex while already holding
      THD::lock_thd_data.
      
      thd_query_safe(): Invoke mysql_mutex_trylock() instead of
      mysql_mutex_lock(). Return the empty string if the mutex
      cannot be acquired without waiting.
      a2560b00
  4. 11 May, 2020 5 commits
  5. 09 May, 2020 1 commit
  6. 08 May, 2020 10 commits
  7. 07 May, 2020 2 commits
    • Marko Mäkelä's avatar
      MDEV-19344 innodb.innodb-change-buffer-recovery fails · 0dee57c6
      Marko Mäkelä authored
      The test was incompatible with ./mtr --repeat=2 until
      commit 2d6719d7
      fixed that.
      
      It turns out that the failing assertion that we disabled in
      commit 3db94d24
      is bogus and can fail when the change buffer is emptied
      during the last batch of crash recovery. The reason for this
      is the condition around the page_create_empty() call in
      page_cur_delete_rec(). The condition was removed in MariaDB
      Server 10.5 as part of MDEV-12353, in
      commit 7ae21b18 and
      commit f8a9f906.
      
      The bug that the assertion aimed to catch is MDEV-22497, which
      was fixed in commit 26aab96e.
      0dee57c6
    • Marko Mäkelä's avatar
      MDEV-22497 [ERROR] InnoDB: Unable to purge a record · 26aab96e
      Marko Mäkelä authored
      The InnoDB insert buffer was upgraded in MySQL 5.5 into a change
      buffer that also covers delete-mark and delete (purge) operations.
      
      There is an important constraint for delete operations: a B-tree
      leaf page must not become empty unless the entire tree becomes empty,
      consisting of an empty root page. Because change buffer merges only
      occur on a single leaf page at a time, delete operations must not be
      buffered if it is possible that the last record of the page could be
      deleted. (In that case, we would refuse to use the change buffer, and
      if we really delete the last record, we would shrink the index tree.)
      
      The function ibuf_get_volume_buffered_hash() is part of our insurance
      that the page would not become empty. It is supposed to map each
      buffered INSERT or DELETE_MARK record payload into a hash value.
      We will only count each such record as a distinct key if there is no
      hash collision. DELETE operations will always decrement the predicted
      number fo records in the page.
      
      Due to a bug in the function, we would actually compute the hash value
      not only on the record payload, but also on some following bytes,
      in case the record contains NULL values. In MySQL Bug #61104, we had
      some examples of this dating back to 2012. But back then, we failed to
      reproduce the bug, and in commit d84c9557
      we simply demoted the hard assertion to a message printout and a debug
      assertion failure.
      
      ibuf_get_volume_buffered_hash(): Correctly compute the hash value
      of the payload bytes only. Note: we will consider
      ('foo','bar'),(NULL,'foobar'),('foob','ar') to be equal, but this
      is not a problem, because in case of a hash collision, we could
      also consider ('boo','far') to be equal, and underestimate the number
      of records in the page, leading to refusing to buffer a DELETE.
      26aab96e
  8. 06 May, 2020 8 commits
  9. 05 May, 2020 2 commits