1. 19 Oct, 2021 2 commits
    • Marko Mäkelä's avatar
      MDEV-26772 InnoDB DDL fails with DUPLICATE KEY error · 6e390a62
      Marko Mäkelä authored
      ha_innobase::delete_table(): When the table that is being dropped
      has a name starting with #sql, temporarily set
      innodb_lock_wait_timeout=0 while attempting to lock the
      persistent statistics tables. If the statistics tables cannot be locked,
      pretend that statistics did not exist and carry on with dropping
      the table. The SQL layer is not really prepared for failures of
      this operation. This is what fixes the test case.
      
      ha_innobase::rename_table(): When renaming a table from a name
      that starts with #sql, try to lock the statistics tables with an
      immediate timeout, and ignore the statistics if the locks were
      not available. In fact, during any rename from a #sql name,
      dict_stats_rename_table() should have no effect, because already
      when an earlier rename to a #sql name took place we should have
      deleted the statistics for the table using the non-#sql name.
      This change is just analogous to the ha_innobase::delete_table().
      6e390a62
    • Krunal Bauskar's avatar
      MDEV-26855: Enable spinning for log_sys_mutex and log_flush_order_mutex · f7684f0c
      Krunal Bauskar authored
      As part of MDEV-26779 we first discovered the effect of enabling spinning for
      some critical mutex. MDEV-26779 tried enabling it for lock_sys.wait_mutex and
      observed a good gain in performance.
      
      In yet another discussion, Mark Callaghan pointed a reference to pthread based
      mutex spin using PTHREAD_MUTEX_ADAPTIVE_NP (MDEV-26769 Intel RTM).
      
      Given the strong references, Marko Makela as part of his comment in #1923
      pointed an idea to enable spinning for other mutexes. Based on perf profiling
      we decided to explore spinning for log_sys_mutex and log_flush_order_mutex as
      they are occupying the top slots in the contented mutex list.
      
      The evaluation showed promising results for ARM64 but not for x86.
      So a patch is here-by proposed to enable the spinning of the mutex for
      ARM64-based platform.
      f7684f0c
  2. 18 Oct, 2021 6 commits
    • Marko Mäkelä's avatar
      MDEV-26554: Races between INSERT on child and DDL on parent table · c3c53926
      Marko Mäkelä authored
      The SQL layer never acquires metadata locks (MDL) on the tables
      that the tables that DML statement accesses is modifying.
      
      However, the storage engine must access the parent table in order to
      ensure that the child table will not refer to a non-existing record
      in the parent table.
      
      During certain DDL operations, the InnoDB table metadata (dict_table_t)
      may be be freed and rebuilt. This would cause a race condition with
      a concurrent INSERT that is attempting to report a FOREIGN KEY violation.
      
      We work around the insufficient MDL during DML by acquiring exclusive
      InnoDB table locks on all child tables during DDL. To avoid deadlocks,
      we will follow the following order of acquisition:
      
      1. tables whose REFERENCES clauses point to the current table
      2. the current table that is being subjected to DDL
      3. mysql.innodb_table_stats
      4. mysql.innodb_index_stats
      5. the InnoDB dictionary tables (SYS_TABLES and so on)
      6. exclusive dict_sys.latch
      c3c53926
    • Marko Mäkelä's avatar
      Merge 10.5 into 10.6 · 59fe6a8a
      Marko Mäkelä authored
      59fe6a8a
    • Nayuta Yanagisawa's avatar
      MDEV-26582 SIGSEGV in spider_db_bulk_insert and spider_db_connect and... · edde9084
      Nayuta Yanagisawa authored
      MDEV-26582 SIGSEGV in spider_db_bulk_insert and spider_db_connect and spider_db_before_query, and hang in "End of update loop" / "Reset for next command" query states
      
      Spider accesses a freed connection in ha_spider::end_bulk_insert()
      and results in SIGSEGV.
      
      The cause of the bug is that ha_spider::is_bulk_insert_exec_period()
      wrongly returns TRUE when the bulk insertion has not yet started.
      
      Spider decides whether it is during the bulk insertion or not by
      the value of insert_pos, but the variable is not reset in a case,
      and this result in the bug.
      edde9084
    • Marko Mäkelä's avatar
      Merge 10.5 into 10.6 · 9c5835e0
      Marko Mäkelä authored
      9c5835e0
    • Marko Mäkelä's avatar
      MDEV-26682 Replication timeouts with XA PREPARE · 18eab4a8
      Marko Mäkelä authored
      The purpose of non-exclusive locks in a transaction is to guarantee
      that the records covered by those locks must remain in that way until
      the transaction is committed. (The purpose of gap locks is to ensure
      that a record that was nonexistent will remain that way.)
      
      Once a transaction has reached the XA PREPARE state, the only allowed
      further actions are XA ROLLBACK or XA COMMIT. Therefore, it can be
      argued that only the exclusive locks that the XA PREPARE transaction
      is holding are essential.
      
      Furthermore, InnoDB never preserved explicit locks across server restart.
      For XA PREPARE transations, we will only recover implicit exclusive locks
      for records that had been modified.
      
      Because of the fact that XA PREPARE followed by a server restart will
      cause some locks to be lost, we might as well always release all
      non-exclusive locks during the execution of an XA PREPARE statement.
      
      lock_release_on_prepare(): Release non-exclusive locks on XA PREPARE.
      
      trx_prepare(): Invoke lock_release_on_prepare() unless the
      isolation level is SERIALIZABLE or this is an internal distributed
      transaction with the binlog (not actual XA PREPARE statement).
      
      This has been discussed with Sergei Golubchik and Andrei Elkin.
      
      Reviewed by: Sergei Golubchik
      18eab4a8
    • Nayuta Yanagisawa's avatar
      MDEV-26539 SIGSEGV in spider_check_and_set_trx_isolation and I_P_List_iterator... · 9068020e
      Nayuta Yanagisawa authored
      MDEV-26539 SIGSEGV in spider_check_and_set_trx_isolation and I_P_List_iterator from THD::drop_temporary_table (10.5.3 opt only) on ALTER
      
      The server crashes if ALTER TABLE, which accesses physical data
      placed at data nodes, is performed on a Spider table.
      
      The cause of the bug is that spider_check_trx_and_get_conn() does
      not allocate connections if sql_command == SQLCOM_ALTER_TABLE.
      Some ALTER TABLE statements, like ALTER TABLE ... CHECK PARTITION,
      access data nodes. So, we need to allocate a new connection before
      performing ALTER TABLEs.
      9068020e
  3. 17 Oct, 2021 1 commit
  4. 15 Oct, 2021 1 commit
  5. 14 Oct, 2021 1 commit
  6. 13 Oct, 2021 13 commits
  7. 12 Oct, 2021 3 commits
  8. 11 Oct, 2021 12 commits
  9. 10 Oct, 2021 1 commit
    • Otto Kekäläinen's avatar
      Deb: Sync build and runtime dependencies from downstream to upstream · cda072bb
      Otto Kekäläinen authored
      - Go back to using $MAJOR_VER instead of hard-coded version strings where
        possible.
      
      - Default to 'auto' in NUMJOBS instead of just 1. Will make mysql-test-run
        faster.
      
      - Unify autopkgtest with latest version in Debian, use eatmydata to make
        mysql-test-run faster.
      
      - Salsa-CI: Remove obsolete 'artifacts: true' as that is the default value.
      
      - Salsa-CI: Clean away obsolete temporary fixes.
      
      - Salsa-CI: Unify with salsa-ci.yml in Debian, including test upgrades
        from Bullseye to Debian unstable.
      cda072bb