1. 20 Aug, 2020 8 commits
    • Marko Mäkelä's avatar
      After-merge fix of the Windows build · 65c43bcf
      Marko Mäkelä authored
      65c43bcf
    • Marko Mäkelä's avatar
      Merge 10.4 into 10.5 · d5d8756d
      Marko Mäkelä authored
      d5d8756d
    • Marko Mäkelä's avatar
      Merge 10.3 into 10.4 · 2fa9f8c5
      Marko Mäkelä authored
      2fa9f8c5
    • Marko Mäkelä's avatar
      Merge 10.2 into 10.3 · de0e7cd7
      Marko Mäkelä authored
      de0e7cd7
    • Thirunarayanan Balathandayuthapani's avatar
      MDEV-23452 Assertion `buf_page_get_io_fix(bpage) == BUF_IO_NONE' failed · a79c2578
      Thirunarayanan Balathandayuthapani authored
      		in buf_page_set_sticky
      
      - Adding os_thread_yield() in buf_page_create() to avoid the continuous
      buffer pool mutex acquistions.
      a79c2578
    • Thirunarayanan Balathandayuthapani's avatar
      MDEV-23452 Assertion `buf_page_get_io_fix(bpage) == BUF_IO_NONE' failed · e9d6f1c7
      Thirunarayanan Balathandayuthapani authored
      			in buf_page_set_sticky
      
      commit a1f899a8 (MDEV-23233) added the
      code to make page sticky. So that InnoDB can't allow the page to
      be grabbed by other thread while doing lazy drop of ahi.
      
      But the block could be in flush list and it could have io_fix value
      as BUF_IO_WRITE. It could lead to the failure in buf_page_set_sticky().
      
      buf_page_create(): If btr_search_drop_page_hash_index() must be invoked,
      take x-latch on the block. If the block io_fix value is other than
      BUF_IO_NONE, release the buffer pool mutex and page hash lock and
      wait for I/O to complete.
      e9d6f1c7
    • Marko Mäkelä's avatar
      MDEV-23514 Race conditions between ROLLBACK and ALTER TABLE · 22c4a751
      Marko Mäkelä authored
      Since commit 15093639 (MDEV-23484)
      the rollback of InnoDB transactions is no longer protected by
      dict_operation_lock. Removing that protection revealed a race
      condition between transaction rollback and the rollback of an
      online table-rebuilding operation (OPTIMIZE TABLE, or any online
      ALTER TABLE that is rebuilding the table).
      
      row_undo_mod_clust(): Re-check dict_index_is_online_ddl() after
      acquiring index->lock, similar to how row_undo_ins_remove_clust_rec()
      is doing it. Because innobase_online_rebuild_log_free() is holding
      exclusive index->lock while invoking row_log_free(), this re-check
      will ensure that row_log_table_low() will not be invoked when
      index->online_log=NULL.
      
      A different race condition is possible between the rollback of a
      recovered transaction and the start of online secondary index creation.
      Because prepare_inplace_alter_table_dict() is not acquiring an InnoDB
      table lock in this case, and because recovered transactions are not
      covered by metadata locks (MDL), the dict_table_t::indexes could be
      modified by prepare_inplace_alter_table_dict() while the rollback of
      a recovered transaction is being executed. Normal transactions would
      be covered by MDL, and during prepare_inplace_alter_table_dict() we
      do hold MDL_EXCLUSIVE, that is, an online ALTER TABLE operation may
      not execute concurrently with other transactions that have accessed
      the table.
      
      row_undo(): To prevent a race condition with
      prepare_inplace_alter_table_dict(), acquire dict_operation_lock
      for all recovered transactions. Before MDEV-23484 we used to acquire
      it for all transactions, not only recovered ones.
      
      Note: row_merge_drop_indexes() would not invoke
      dict_index_remove_from_cache() while transactional locks
      exist on the table, or while any thread is holding an open table handle.
      OK, it does that for FULLTEXT INDEX, but ADD FULLTEXT INDEX is not
      supported as an online operation, and therefore
      prepare_inplace_alter_table_dict() would acquire a table S lock,
      which cannot succeed as long as recovered transactions on the table
      exist, because they would hold a conflicting IX lock on the table.
      22c4a751
    • Marko Mäkelä's avatar
      Merge 10.1 into 10.2 · bfba2bce
      Marko Mäkelä authored
      bfba2bce
  2. 19 Aug, 2020 6 commits
  3. 18 Aug, 2020 7 commits
    • Marko Mäkelä's avatar
      MDEV-23484 Rollback unnecessarily acquires dict_operation_lock for every row · 15093639
      Marko Mäkelä authored
      InnoDB transaction rollback includes an unnecessary work-around for
      a data corruption bug that was fixed by me in MySQL 5.6.12
      mysql/mysql-server@935ba09d52c1908bde273ad1940b5ab919d9763d
      and ported to MariaDB 10.0.8 by
      commit c291ddfd
      in 2013 and 2014, respectively.
      
      By acquiring and releasing dict_operation_lock in shared mode,
      row_undo() hopes to prevent the table from being dropped while
      the undo log record is being rolled back. But, thanks to mentioned fix,
      debug assertions (that we are adding) show that the rollback is
      protected by transactional locks (table IX lock, in addition to
      implicit or explicit exclusive locks on the records that had been modified).
      
      Because row_drop_table_for_mysql() would invoke
      row_add_table_to_background_drop_list() if any locks exist on the table,
      the mere existence of locks (which is guaranteed during ROLLBACK) is
      enough to protect the table from disappearing. Hence, acquiring and
      releasing dict_operation_lock for every row that is being rolled back is
      unnecessary.
      
      row_undo(): Remove the unnecessary acquisition and release of
      dict_operation_lock.
      
      Note: row_add_table_to_background_drop_list() is mostly working around
      bugs outside InnoDB:
      MDEV-21175 (insufficient MDL protection of FOREIGN KEY operations)
      MDEV-21602 (incorrect error handling of CREATE TABLE...SELECT).
      15093639
    • Marko Mäkelä's avatar
      MDEV-23474 InnoDB fails to restart after SET GLOBAL innodb_log_checksums=OFF · 4c50120d
      Marko Mäkelä authored
      Regretfully, the parameter innodb_log_checksums was introduced
      in MySQL 5.7.9 (the first GA release of that series) by
      mysql/mysql-server@af0acedd885eb7103e319f79d25fda7386ef1506
      which partly replaced a parameter that had been introduced in 5.7.8
      mysql/mysql-server@22ba38218e1d76c24f69b5a5595ad3bf5933acb0
      as innodb_log_checksum_algorithm.
      
      Given that the CRC-32C operations are accelerated on many processor
      implementations (AMD64 with SSE4.2; since MDEV-22669 also on IA-32
      with SSE4.2, POWER 8 and later, ARMv8 with some extensions)
      and by lookup tables when only generic SISD instructions are available,
      there should be no valid reason to disable checksums.
      
      In MariaDB 10.5.2, as a preparation for MDEV-12353, MDEV-19543 deprecated
      and ignored the parameter innodb_log_checksums altogether. This should
      imply that after a clean shutdown with innodb_log_checksums=OFF one
      cannot upgrade to MariaDB Server 10.5 at all.
      
      Due to these problems, let us deprecate the parameter innodb_log_checksums
      and honor it only during server startup.
      The command SET GLOBAL innodb_log_checksums will always set the
      parameter to ON.
      4c50120d
    • Marko Mäkelä's avatar
      MDEV-23499 Assertion c.same_type(*o) failed · 064bfbaf
      Marko Mäkelä authored
      dict_col_t::same_encoding(), dict_col_t::same_format(): Allow
      an instantaneous change of a column to a compatible encoding,
      just like ha_innobase::can_convert_string() and similar functions do.
      064bfbaf
    • Thirunarayanan Balathandayuthapani's avatar
      MDEV-22934 Table disappear after two alter table command · 8268f266
      Thirunarayanan Balathandayuthapani authored
      Problem:
      =======
      InnoDB drops the column which has foreign key relations on it. So it
      tries to load the foreign key during rename process of copy algorithm
      even though the foreign_key_check is disabled.
      
      Solution:
      ========
      During alter copy algorithm, InnoDB ignores the error while loading
      the foreign key constraint if foreign key check is disabled. It
      should throw the warning about failure of the foreign key constraint
      when foreign key check is disabled.
      8268f266
    • Thirunarayanan Balathandayuthapani's avatar
      MDEV-23380 InnoDB reads a page from disk despite parsing MLOG_INIT_FILE_PAGE2 record · 362b18c5
      Thirunarayanan Balathandayuthapani authored
      This problem is caused by 6697135c
      (MDEV-21572). During recovery, InnoDB prefetches the siblings of
      change buffer index leaf page. It does asynchronous page read
      and recovery scenario wasn't handled in buf_read_page_background().
      It leads to the refusal of startup of the server.
      
      Solution:
      =========
        InnoDB shouldn't allow the change buffer index page siblings
      to be prefetched.
      362b18c5
    • Oleksandr Byelkin's avatar
      MDEV-23491: __bss_start breaks compilation of various platforms · ece0b062
      Oleksandr Byelkin authored
      Remove __bss_start & Co, because systen call "write" check buffer address and return EFAULT if it is wrong.
      ece0b062
    • Julius Goryavsky's avatar
      MDEV-21039: Server fails to start with unknown mysqld_safe options · 57960211
      Julius Goryavsky authored
      Adding any unknown option to the "[mysqld_safe]" section makes
      mysqld impossible to start with mysqld_multi. For example, after
      adding the unknown option "numa_interleave" to the "[mysqld_safe]"
      section, mysqld_multi exits with the following diagnostics:
      
      [ERROR] /usr/local/mysql/bin/mysqld: unknown option '--numa_interleave'
      
      To get rid of this behavior, this patch by default adds the "--loose-"
      prefix to all unknown (for mysqld_safe) options. This behavior can be
      enabled explicitly with the --ignore-unknown option and disabled with
      the --no-ignore-unknown option.
      57960211
  4. 17 Aug, 2020 2 commits
  5. 15 Aug, 2020 3 commits
    • Eugene Kosov's avatar
      MDEV-21251 CHECK TABLE fails to check info_bits of records · 90c8d773
      Eugene Kosov authored
      btr_validate_index(): do not stop checking after some level failed.
      That way it'll become possible to see errors in leaf pages even when
      uppers layers are corrupted too.
      
      page_validate(): check info_bits and status_bits more
      90c8d773
    • Vladislav Vaintroub's avatar
      MDEV-23489 Windows zip files 10.4.14 have an embryonic data folder · 010fd61a
      Vladislav Vaintroub authored
      Fix : Do not INSTALL anything with cmake from data folder.
      010fd61a
    • Daniel Black's avatar
      MDEV-23440: mysql_tzinfo_to_sql to use transactions · b970363a
      Daniel Black authored
      Since MDEV-18778, timezone tables get changed to innodb
      to allow them to be replicated to other galera nodes.
      
      Even without galera, timezone tables could be declared innodb.
      With the standalone innodb tables, the mysql_tzinfo_to_sql takes
      approximately 27 seconds.
      
      With the transactions enabled in this patch, 1.2 seconds is
      the approximate load time.
      
      While explicit checks for the engine of the time zone tables could be
      done, or checks against !opt_skip_write_binlog, non-transactional
      storage engines will just ignore the transactional state without
      even a warning so its safe to enact globally.
      
      Leap seconds are pretty much ignored as they are a single insert
      statement and have gone out of favour as they have caused MariaDB
      stalls in the past.
      b970363a
  6. 13 Aug, 2020 1 commit
  7. 14 Aug, 2020 2 commits
  8. 13 Aug, 2020 1 commit
  9. 14 Aug, 2020 10 commits