1. 06 Jul, 2018 3 commits
    • Marko Mäkelä's avatar
      Merge 10.2 into 10.3 · 934d5f95
      Marko Mäkelä authored
      934d5f95
    • Thirunarayanan Balathandayuthapani's avatar
      MDEV-15855 Deadlock between purge thread and DDL statement · 8b0d4cff
      Thirunarayanan Balathandayuthapani authored
      Problem:
      ========
      Truncate operation holds MDL on the table (t1) and tries to
      acquire InnoDB dict_operation_lock. Purge holds dict_operation_lock
      and tries to acquire MDL on the table (t1) to evaluate virtual
      column expressions for indexed virtual columns.
      It leads to deadlock of purge and truncate table (DDL).
      
      Solution:
      =========
      If purge tries to acquire MDL on the table then it should do the following:
      
      i) Purge should release all innodb latches (including dict_operation_lock)
      before acquiring metadata lock on the table.
      
      ii) After acquiring metadata lock on the table, it should check whether the
      table was dropped or renamed. If the table is dropped then purge should
      ignore the undo log record. If the table is renamed then it should
      release the old MDL and acquire MDL on the new name.
      
      iii) Once purge acquires MDL, it should use the SQL table handle for all
      the remaining virtual index for the purge record.
      
      purge_node_t: Introduce new virtual column information to know whether
      the MDL was acquired successfully.
      
      This is joint work with Marko Mäkelä.
      8b0d4cff
    • Marko Mäkelä's avatar
      MDEV-14188 mariabackup.incremental_encrypted wrong result · e3207b6c
      Marko Mäkelä authored
      Add an explicit redo log flush. In this test
      innodb_flush_log_at_trx_commit was 2 by default.
      It is also possible that this failure occurs because of MDEV-15740.
      e3207b6c
  2. 05 Jul, 2018 7 commits
  3. 03 Jul, 2018 4 commits
    • Marko Mäkelä's avatar
      MDEV-16675 Unnecessary explicit lock acquisition during UPDATE or DELETE · 1748a31a
      Marko Mäkelä authored
      In InnoDB, an INSERT will not create an explicit lock object. Instead,
      the inserted record is initially implicitly locked by the transaction
      that wrote its trx_t::id to the hidden system column DB_TRX_ID.
      (Other transactions would check if DB_TRX_ID is referring to a
      transaction that has not been committed.)
      
      If a record was inserted in the current transaction, it would be
      implicitly locked by that transaction. Only if some other transaction
      is requesting access to the record, the implicit lock should be
      converted to an explicit one, so that the waits-for graph can be
      constructed for detecting deadlocks and lock wait timeouts.
      
      Before this fix, InnoDB would convert implicit locks to
      explicit ones, even if no conflict exists.
      
      lock_rec_convert_impl_to_expl(): Return whether caller_trx
      already holds an explicit lock that covers the record.
      
      row_vers_impl_x_locked_low(): Avoid a lookup if the record matches
      caller_trx->id.
      
      lock_trx_has_expl_x_lock(): Renamed from lock_trx_has_rec_x_lock().
      
      row_upd_clust_step(): In a debug assertion, check for implicit lock
      before invoking lock_trx_has_expl_x_lock().
      
      rw_trx_hash_t::find(): Make do_ref_count a mandatory parameter.
      Assert that trx_id is not 0 (the caller should check it).
      
      trx_sys_t::is_registered(): Only invoke find() if id != 0.
      
      trx_sys_t::find(): Add the optional parameter do_ref_count.
      
      lock_rec_queue_validate(): Avoid lookup for trx_id == 0.
      1748a31a
    • Marko Mäkelä's avatar
      Merge 10.2 into 10.3 · 186a998b
      Marko Mäkelä authored
      186a998b
    • Marko Mäkelä's avatar
      Merge mariadb-10.3.8 into 10.3 · c3289d27
      Marko Mäkelä authored
      c3289d27
    • Daniel Bartholomew's avatar
      bump the VERSION · 358ae4b4
      Daniel Bartholomew authored
      358ae4b4
  4. 02 Jul, 2018 6 commits
  5. 01 Jul, 2018 4 commits
  6. 30 Jun, 2018 9 commits
  7. 29 Jun, 2018 7 commits