1. 13 Aug, 2021 1 commit
    • Sujatha's avatar
      MDEV-25962: binlog.binlog_truncate_multi_log_unsafe test fails in buildbot · 583516bb
      Sujatha authored
      1. sync_binlog=1 is needed to ensure that on flush binlog is available on
         disk.
      2. Insert on 'connection master2' should wait for 'master1_ready' from
         'connection master1'.
      
      Added sync_binlog=1 to all tests that got added as part of MDEV-21117 fix
      
      @mysql-test/suite/binlog/t/binlog_truncate_multi_log_unsafe.test
      @mysql-test/suite/binlog/t/binlog_truncate_multi_engine.test
      @mysql-test/suite/binlog/t/binlog_truncate_active_log.test
      @mysql-test/suite/binlog/t/binlog_truncate_multi_log.test
      583516bb
  2. 11 Aug, 2021 1 commit
  3. 09 Aug, 2021 2 commits
  4. 06 Aug, 2021 1 commit
  5. 05 Aug, 2021 3 commits
  6. 03 Aug, 2021 2 commits
  7. 02 Aug, 2021 10 commits
  8. 01 Aug, 2021 1 commit
    • Sergei Golubchik's avatar
      suppress galera error "Failed to report last committed" · ec8882b9
      Sergei Golubchik authored
      according to MDEV-17550 it's informational, not fatal.
      "last committed" is part of the certification index purge process.
      
      depending on what tests and in what order are run it can be triggered
      at unspecified times during the testing. If the test is happen to
      shut down the server at this very time, the log will have:
      
      [Warning] WSREP: Failed to report last committed XXXYYYZZZ, -77 (File descriptor in bad state)
      ec8882b9
  9. 31 Jul, 2021 3 commits
  10. 30 Jul, 2021 5 commits
  11. 29 Jul, 2021 11 commits
    • Oleksandr Byelkin's avatar
    • Marko Mäkelä's avatar
      MDEV-19445/MDEV-16678 fixup: Acquire proper MDL on innodb_ft_aux_table · 0aa2bc7a
      Marko Mäkelä authored
      In commit 2647fd10 (MDEV-19445)
      we fixed a race condition around the INFORMATION_SCHEMA tables
      that access the table identified by the global variable
      innodb_ft_aux_table. Thanks to MDEV-16678 we could fix it
      even better by using MDL instead of the InnoDB dict_sys latches.
      0aa2bc7a
    • Marko Mäkelä's avatar
      MDEV-21175 follow-up: Remove redundant locking; rely on MDL · e305493b
      Marko Mäkelä authored
      Before entering DML or DDL execution in the storage engine, the SQL layer
      will have acquired metadata lock (MDL) on the current table name as well
      as the names of FOREIGN KEY (grand)child tables (that is,
      tables whose REFERENCES clauses point to the current table).
      The MDL prevents any metadata changes to these tables, such as
      RENAME, TRUNCATE, DROP, ALTER.
      
      While the MDL on the current table prevents dict_table_t::foreign_set
      from being modified, it does not prevent the table metadata that the
      stored pointers are pointing to from being modified.
      
      The MDL on the child tables will prevent both dict_table_t::referenced_set
      as well as the pointed child table metadata from being modified.
      
      wsrep_row_upd_index_is_foreign(): Do not unnecessarily acquire the
      data dictionary latch if Galera replication is not enabled.
      
      ha_innobase::can_switch_engines(): Rely on MDL. We are not dereferencing
      any pointers stored in the sets.
      
      row_mysql_freeze_data_dictionary(), row_mysql_unfreeze_data_dictionary():
      Remove.
      
      row_update_for_mysql(): Call init_fts_doc_id_for_ref() only once.
      
      In ALTER TABLE...IMPORT TABLESPACE and FLUSH TABLES...FOR EXPORT
      the SQL layer is protecting the current table with MDL. We do not
      need InnoDB latches.
      e305493b
    • Marko Mäkelä's avatar
      MDEV-23484 Rollback unnecessarily acquires dict_sys.latch · 86a14289
      Marko Mäkelä authored
      row_undo(): Remove the unnecessary acquisition and release of
      dict_sys.latch. This was supposed to prevent the table from being
      dropped while the undo log record is being rolled back. But, thanks to
      trx_resurrect_table_locks() that was introduced in
      mysql/mysql-server@935ba09d52c1908bde273ad1940b5ab919d9763d
      and commit c291ddfd
      as well as commit 1bd681c8
      (MDEV-25506 part 3) tables will be protected against dropping
      due to table locks.
      
      This reverts commit 0049d5b5
      (which had reverted a previous attempt of fixing this) and addresses
      an earlier race condition with the following:
      
      prepare_inplace_alter_table_dict(): If recovered transactions hold
      locks on the table while we are executing online ADD INDEX, acquire
      a table lock so that the rollback of those recovered transactions will
      not interfere with the ADD INDEX.
      86a14289
    • Marko Mäkelä's avatar
      Cleanup: Remove pars_stored_procedure_call() · 15363a4f
      Marko Mäkelä authored
      The InnoDB internal SQL parser never supported this syntax.
      15363a4f
    • Marko Mäkelä's avatar
      MDEV-25506 fixup: Correct a bogus comment · 92046ba2
      Marko Mäkelä authored
      Since commit 1bd681c8 tablespaces are
      dropped after the table has been dropped. No dict_sys latch protection
      is relevant during the execution of fil_delete_tablespace().
      92046ba2
    • Marko Mäkelä's avatar
      Cleanup: Remove a workaround · 72764b2f
      Marko Mäkelä authored
      Since commit 1bd681c8
      dict_stats_exec_sql() is no longer playing dirty tricks.
      We can remove the workaround in lock_release().
      72764b2f
    • Marko Mäkelä's avatar
      MDEV-26274 fts_lock_table() attempts to release unreserved dict_sys.mutex · e8ba6426
      Marko Mäkelä authored
      fts_lock_table(): Fix a regression that was introduced in
      commit da65cb4d (MDEV-25936).
      e8ba6426
    • Oleksandr Byelkin's avatar
      Merge branch '10.2' into 10.3 · 83d7e4fa
      Oleksandr Byelkin authored
      83d7e4fa
    • Nikita Malyavin's avatar
      MDEV-20154 Assertion `len <= col->len | ...` failed in row_merge_buf_add · 22709897
      Nikita Malyavin authored
      len was containing garbage, since vctempl->mysql_col_offset was
      containing old value while calling row_mysql_store_col_in_innobase_format
      from innobase_get_computed_value().
      
      It was not updated after the first ALTER TABLE call, because it's INPLACE
      logic considered there's nothing to update, and exited immediately from
      ha_innobase::inplace_alter_table().
      
      However, vcol metadata needs an update, since vcols structure is changed
      in mysql record.
      
      The regression was introduced by 12614af1. There, refcount==1 condition
      was removed, which turned out to be crucial, though racy. The idea was to
      update vc_templ after each (sequencing) ALTER TABLE.
      
      We should do the same another way, and there may be a plenty of solutions,
      but the simplest one is to add a following condition:
        if vcol structure is changed, drop vc_templ; it will be recreated on next
        ha_innobase::open() call.
      
      in prepare_inplace_alter_table. It is safe, since innodb inplace changes
      require at least HA_ALTER_INPLACE_SHARED_LOCK_AFTER_PREPARE, which
      guarantee MDL_EXCLUSIVE on this stage.
      
      alter_templ_needs_rebuild() also has to track the columns not indexed, to
      keep vc_templ correct.
      
      Note that vc_templ is always kept constructed and available after
      ha_innobase::open() call, even on INSERT, though no virtual columns are
      evaluated during that statement
      inside innodb.
      
      In the test case suplied, it will be recreated on the second ALTER TABLE.
      22709897
    • Marko Mäkelä's avatar
      Cleanup: Remove redundant conditions · 0e8981ef
      Marko Mäkelä authored
      ha_innobase::prepare_inplace_alter_table(): Remove always-true conditions.
      Near the start of the function, we would already have returned if
      no ALTER TABLE operation flags were set that would require special
      action from InnoDB.
      
      It turns out that the conditions were redundant already when they were
      introduced in mysql/mysql-server@241387a2b6b61fb8a4f78dc4ad0aaa289400c694
      and in commit 068c6197.
      
      Thanks to Nikita Malyavin for noticing this.
      0e8981ef