1. 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
  2. 17 Oct, 2021 1 commit
  3. 15 Oct, 2021 1 commit
  4. 14 Oct, 2021 1 commit
  5. 13 Oct, 2021 13 commits
  6. 12 Oct, 2021 3 commits
  7. 11 Oct, 2021 12 commits
  8. 10 Oct, 2021 2 commits
    • 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
    • Otto Kekäläinen's avatar
      Deb: Correctly install test_sql_service.so · 9bb65206
      Otto Kekäläinen authored
      Completes the change that was attempted in 5ca14daf (MDEV-19275).
      9bb65206
  9. 08 Oct, 2021 1 commit