1. 01 Dec, 2020 2 commits
  2. 18 Nov, 2020 4 commits
    • Aleksey Midenkov's avatar
      table_flags fix · 4310cbfc
      Aleksey Midenkov authored
      "debug" deviation is now gone.
      4310cbfc
    • Aleksey Midenkov's avatar
      MDEV-21652 Foreign key migration from old version · 04aef4c4
      Aleksey Midenkov authored
      == fk_check_legacy_storage(), fk_upgrade_legacy_storage() ==
      
      fk_check_legacy_storage() checks whether upgrade is required for the
      given table name by looking SYS_FOREIGN table for corresponding record
      existence.
      
      fk_upgrade_legacy_storage() does the upgrade routine which includes
      getting the foreign keys from SYS_FOREIGN[_COLS], updating the
      foreign/referenced shares as well as their FRM files, deleting the
      records from SYS_FOREIGN[_COLS] tables.
      
      Both routines utilize the internal SQL for SYS_FOREIGN[_COLS]
      processing.
      
      == Upgrade foreign keys via backoff action ==
      
      When table is opened fk_check_legacy_storage() detects whether upgrade
      is required and HA_ERR_FK_UPGRADE is returned to SQL layer which then
      handles this error by backoff action from Open_table_context where
      table is opened again with HA_OPEN_FOR_REPAIR flag which indicates
      that fk_upgrade_legacy_storage() is required. After
      fk_upgrade_legacy_storage() is done fk_check_legacy_storage() is
      checked again to ensure that SYS_FOREIGN[_COLS] are empty for the
      given table.
      
      == Check foreign/referenced indexes existence ==
      
      fk_upgrade_legacy_storage() via fk_upgrade_push_fk() fails if there
      are no indexes in foreign/referenced tables for the given data
      acquired from SYS_FOREIGN[_COLS].
      
      == Internal SQL: select into both func and vars extension ==
      
      fk_upgrade_legacy_storage() utilizes syntax extension in internal SQL:
      
        FETCH c INTO fk_upgrade_create_fk() fk_id, unused;
      
      Thus the data is fetched into both fk_upgrade_create_fk() function and
      fk_id variable.
      
      == Rename table, rename column, drop table, drop column handling ==
      
      When foreign table is opened it is automatically upgraded by backoff
      action. But if the referenced table is altered or dropped first there
      is no chance for the foreign table to get the correct data. So the
      SYS_FOREIGN_[COLS] must be kept in sync with the above DDL operations
      in respect of referenced names. DROP TABLE for the referenced table is
      disabled as usual. DROP TABLE, DROP COLUMN relied in 10.5 on
      dict_foreign_t cached data for the referenced tables. Now there is no
      such possibility for the legacy data so we have to look at
      SYS_FOREIGN_[COLS] directly.
      
      == Reverted some SYS_FOREIGN(_COLS) routines ==
      
      Rename table and rename column handling was done in sync with
      SYS_FOREIGN_[COLS] in 10.5. To retain the above DDL consistency for
      the referenced tables we still use that old synchronization code.
      
      == ALGORITHM=COPY handling ==
      
      Since we cannot faingrain ALGORITHM=COPY in innobase handler it is
      disabled for the referenced tables unless the foreign tables are upgraded.
      
      The check is done in create_table_info_t::create_table() and is
      equivalent to DROP TABLE check as we are actually dropping the old
      table after the copy routine is done.
      
      == WITH_INNODB_LEGACY_FOREIGN_STORAGE macro ==
      
      Every SYS_FOREIGN_[COLS] handling is wrapped inside
      WITH_INNODB_LEGACY_FOREIGN_STORAGE compilation macro. When this macro
      is disabled the foreign key upgrade is not possible. Future versions
      will obsolete the upgrade completely.
      
      == innodb_eval_sql debug interface ==
      
      Test cases must fill SYS_FOREIGN_[COLS] with data. This is done with
      setting the new innodb_eval_sql debug variable. The value of that
      variable is processed by que_eval_sql().
      
      == Some syntax error-friendly parser handling ==
      
      que_eval_sql() was unfriendly on syntax errors: it just failed with
      SIGABRT exception. To keep the server alive some frequent syntax
      errors are now returned as DB_ERROR from que_eval_sql().
      04aef4c4
    • Aleksey Midenkov's avatar
      MDEV-21052 InnoDB foreign key refactoring for TABLE_SHARE::foreign_keys · b56f4a87
      Aleksey Midenkov authored
      Refactor dict_load_foreigns() for synchronising TABLE_SHARE foreign
      data with dict_table_t cache.
      
      Remove a number of routines working with SYS_FOREIGNS and
      SYS_FOREIGN_COLS. innobase_update_foreign_try() is now used solely for
      ER_FK_INCORRECT_OPTION check.
      
      Prelock parent tables as well as child tables. This is done for the
      case when parent table doesn't know about its children when they
      created before parent with foreign_key_checks=0. Opening the parent
      table initiates fk_resolve_referenced_keys() which updates its
      referenced_keys. Due to CREATE TABLE doesn't not know about "illegal"
      children it can not check for foreign consistency. F.ex. this would
      succeed:
      
      set foreign_key_checks= 0;
      create table child (fk int references parent (id)) engine=innodb;
      set foreign_key_checks= 1;
      
      create table parent (id bigint primary key) engine=innodb;
      
      In the above case dict_load_foreigns() deduces which tables are
      unknown to opened parent (tables_missing) and reloads their foreign
      data via recursion. Infinite recursion is not possible via test case:
      a table cannot be "parent after child" and "child before parent"
      simultaneously. Though infinite recursion is possible via malicously
      crafted FRM file, there is no protection from that at InnoDB level but
      there is protection at SQL level: thd->fk_circular_check.
      
      Later though it would not allow DML on child as well as on parent (see
      innodb.foreign_key MDEV-10083). So this is pretty acceptable:
      foreign_key_checks is unnormal setting, checking parent on CREATE
      TABLE would impose all frms scanning which is not acceptable.
      
      ha_innobase::open() then synchronizes these referenced_keys with its
      referenced_set cache by calling dict_load_foreigns().
      
      Disable self-references on same column. The Bug 12902967 restricted
      them on some condition of "same column/index" (see
      innodb_bug12902967.test), though such self-references were not
      completely disabled (see other self-ref cases changed in this
      patch). It is not clear why they worked if they are "self-refs on same
      column/index".
      b56f4a87
    • Aleksey Midenkov's avatar
      MDEV-20865 Store foreign key info in TABLE_SHARE · f12c5f96
      Aleksey Midenkov authored
      1. Access foreign keys via TABLE_SHARE::foreign_keys and
        TABLE_SHARE::referenced_keys;
      
      foreign_keys and referenced_keys are objects in TABLE_SHARE.
      
      2. Remove handler FK interface:
      
        - get_foreign_key_list()
        - get_parent_foreign_key_list()
        - referenced_by_foreign_key()
      
      3. Invalidate referenced shares on:
      
        - RENAME TABLE
        - DROP TABLE
        - RENAME COLUMN
        - ADD FOREIGN KEY
      
      When foreign table is created or altered by the above operations all
      referenced shares are closed. This blocks the operation while any
      referenced shares are used (when at least one its TABLE instance is
      locked).
      
      4. Update referenced shares on:
      
        - CREATE TABLE
      
      On CREATE TABLE add items to referenced_keys of referenced shares.
      
      5. Invalidate foreign shares on:
      
        - RENAME TABLE
        - RENAME COLUMN
      
      The above-mentioned blocking takes effect.
      
      6. Check foreign/referenced shares consistency on:
      
        - CHECK TABLE
      
      7. Temporary change until MDEV-21051:
      
      InnoDB fill foreign key info at handler open().
      
      On first TABLE open FK info is loaded from storage engine into
      TABLE_SHARE. All referenced shares (if any exist) are closed. This
      leads to blocking of first time foreign table open while referenced
      tables are used.
      
      Restore states of referenced shares in case of errors.
      
      FOREIGN_KEY_INFO refactored to FK_info holding Lex_cstring
      
      (MDEV-21311) Converge Foreign_key and supplemental generated Key together
      
      mysql_prepare_create_table() does data validation and such utilities
      as automatic name generation. But it does that only for indexes and
      ignores Foreign_key objects. Now as Foreign_key data needs to be
      stored in FRM files as well this processing must be done for them like
      for any other Key objects.
      
      Replace Key::FOREIGN_KEY type with Key::foreign flag of type
      Key::MULTIPLE and Key::generated set to true. Construct one object
      with Key::foreign == true instead of two objects of type
      Key::FOREIGN_KEY and Key::MULTIPLE.
      
      (MDEV-21051) datadict refactorings
      
      - Move read_extra2() to datadict.cc
      - Refactored extra2_fields to Extra2_info
      - build_frm_image() readability
      
      (MDEV-21051) build_table_shadow_filename() refactoring
      
      mysql_prepare_alter_table() leaks fixes
      
      (MDEV-21051) amend system tables locking restriction
      
      Table mysql.help_relation has foreign key to mysql.help_keyword. On
      bootstrap when help_relation is opened, it preopens help_keyword for
      READ and fails in lock_tables_check().
      
      If system table is opened for write then fk references are opened for
      write.
      
      Related to: Bug#25422, WL#3984
      Tests: main.lock
      
      (MDEV-21051) Store and read foreign key info into/from FRM files
      
      1. Introduce Foreign_key_io class which creates/parses binary stream
      containing foreign key structures. Referenced tables store there only
      hints about foreign tables (their db and name), they restore full info
      from the corresponding tables.
      
      Foreign_key_io is stored under new EXTRA2_FOREIGN_KEY_INFO field in
      extra2 section of FRM file.
      
      2. Modify mysql_prepare_create_table() to generate names for foreign
      keys. Until InnoDB storage of foreign keys is removed, FK names must
      be unique across the database: the FK name must be based on table
      name.
      
      3. Keep stored data in sync on DDL changes. Referenced tables update
      their foreign hints after following operations on foreign tables:
      
        - RENAME TABLE
        - DROP TABLE
        - CREATE TABLE
        - ADD FOREIGN KEY
        - DROP FOREIGN KEY
      
      Foreign tables update their foreign info after following operations on
      referenced tables:
      
        - RENAME TABLE
        - RENAME COLUMN
      
      4. To achieve 3. there must be ability to rewrite extra2 section of
      FRM file without full reparse. FRM binary is built from primary
      structures like HA_CREATE_INFO and cannot be built from TABLE_SHARE.
      
      Use shadow write and rename like fast_alter_partition_table() does.
      
      Create table workflow:
      
      1. Foreign_key is constructed in parser, placed into alter_info->key_list;
      
      2. mysql_prepare_create_table() translates them to FK_info, assigns
         foreign_id if needed;
      
      3. build_frm_image() writes two FK_info lists into FRM's extra2
         section, for referenced keys it stores only table names (hints);
      
      4. init_from_binary_frm_image() parses extra2 section and fills
         foreign_keys and referenced_keys of TABLE_SHARE.
      
         It restores referenced_keys by reading hint list of table names,
         opening corresponding shares and restoring FK_info from their
         foreign_keys. Hints resolution is done only when initializing
         non-temporary shares. Usually temporary share has different
         (temporary) name and it is impossible to resolve foreign keys by that
         name (as we identify them by both foreign and referenced table
         names). Another not unimportant reason is performance: this saves
         spare share acquisitions.
      
      Alter table workflow:
      
      1. Foreign_key is constructed in parser, placed into
         alter_info->key_list;
      
      2. mysql_prepare_alter_table() prepares action lists and share list of
         foreigns/references;
      
      3. mysql_prepare_alter_table() locks list of foreigns/references by
         MDL_INTENTION_EXCLUSIVE, acquires shares;
      
      4. prepare_create_table() converts key_list into FK_list, assigns
         foreign_id;
      
      5. shadow FRM of altered table is created;
      
      6. data is copied;
      
      7. altered table is locked by MDL_EXCLUSIVE;
      
      8. fk_handle_alter() processes action lists, creates FK backups,
         modifies shares, writes shadow FRMs;
      
      9. altered table is closed;
      
      10. shadow FRMs are installed;
      
      11. altered table is renamed, FRM backup deleted;
      
      12. (TBD in MDEV-21053) shadow FRMs installation log closed, backups deleted;
      
      On FK backup system:
      
      In case of failed DDL operation all shares that was modified must be
      restored into original state. This is done by FK_ddl_backup (CREATE,
      DROP), FK_rename_backup (RENAME), FK_alter_backup (ALTER).
      
      On STL usage:
      
      STL is used for utility not performance-critical algorithms, core
      structures hold native List. A wrapper was made to convert STL
      exception into bool error status or NULL value.
      
      MDEV-20865 fk_check_consistency() in CHECK TABLE
      
      Self-refs fix
      f12c5f96
  3. 08 Sep, 2020 2 commits
  4. 07 Sep, 2020 1 commit
  5. 02 Sep, 2020 1 commit
  6. 01 Sep, 2020 1 commit
  7. 26 Aug, 2020 1 commit
  8. 25 Aug, 2020 2 commits
  9. 24 Aug, 2020 1 commit
  10. 23 Aug, 2020 2 commits
  11. 22 Aug, 2020 3 commits
    • Alexander Barkov's avatar
      MDEV-23537 Comparison with temporal columns is slow in MariaDB · 2e5d86f4
      Alexander Barkov authored
      Implementing methods:
      - Field::val_time_packed()
      - Field::val_datetime_packed()
      - Item_field::val_datetime_packed(THD *thd);
      - Item_field::val_time_packed(THD *thd);
      to give a faster access to temporal packed longlong representation of a Field,
      which is used in temporal Arg_comparator's to DATE, TIME, DATETIME data types.
      
      The same idea is used in MySQL-5.6+.
      
      This improves performance.
      2e5d86f4
    • Alexander Barkov's avatar
      6708e67a
    • Alexander Barkov's avatar
      MDEV-23525 Wrong result of MIN(time_expr) and MAX(time_expr) with GROUP BY · ae33ebe5
      Alexander Barkov authored
      Problem:
      
      When calculatung MIN() and MAX() in a query with GROUP BY, like this:
      
        SELECT MIN(time_expr), MAX(time_expr) FROM t1 GROUP BY i;
      
      the code in Item_sum_min_max::update_field() erroneosly used
      string format comparison, therefore '100:20:30' was considered as
      smaller than '10:20:30'.
      
      Fix:
      
      1. Implementing low level "native" related methods in class Time:
           Time::Time(const Native &native)           - convert native to Time
           Time::to_native(Native *to, uint decimals) - convert Time to native
      
         The "native" binary representation for TIME is equal to
         the binary data format of Field_timef, which is used to
         store TIME when mysql56_temporal_format is ON (default).
      
      2. Implementing Type_handler_time_common "native" related methods:
      
        Type_handler_time_common::cmp_native()
        Type_handler_time_common::Item_val_native_with_conversion()
        Type_handler_time_common::Item_val_native_with_conversion_result()
        Type_handler_time_common::Item_param_val_native()
      
      3. Implementing missing "native representation" related methods
         in Field_time and Field_timef:
      
        Field_time::store_native()
        Field_time::val_native()
        Field_timef::store_native()
        Field_timef::val_native()
      
      4. Implementing missing "native" related methods in all Items
         that can have the TIME data type:
      
        Item_timefunc::val_native()
        Item_name_const::val_native()
        Item_time_literal::val_native()
        Item_cache_time::val_native()
        Item_handled_func::val_native()
      
      5. Marking Type_handler_time_common as "native ready".
         So now Item_sum_min_max::update_field() calculates
         values using min_max_update_native_field(),
         which uses native binary representation rather than string representation.
      
         Before this change, only the TIMESTAMP data type used native
         representation to calculate MIN() and MAX().
      
      Benchmarks (see more details in MDEV):
      
        This change not only fixes the wrong result, but also
        makes a "SELECT .. MAX.. GROUP BY .." query faster:
      
        # TIME(0)
        CREATE TABLE t1 (id INT, time_col TIME) ENGINE=HEAP;
        INSERT INTO t1 VALUES (1,'10:10:10'); -- repeat this 1m times
        SELECT id, MAX(time_col) FROM t1 GROUP BY id;
      
        MySQL80: 0.159 sec
        10.3:    0.108 sec
        10.4:    0.094 sec (fixed)
      
        # TIME(6):
        CREATE TABLE t1 (id INT, time_col TIME(6)) ENGINE=HEAP;
        INSERT INTO t1 VALUES (1,'10:10:10.999999'); -- repeat this 1m times
        SELECT id, MAX(time_col) FROM t1 GROUP BY id;
      
        My80: 0.154
        10.3: 0.135
        10.4: 0.093 (fixed)
      ae33ebe5
  12. 21 Aug, 2020 15 commits
    • Ian Gilfillan's avatar
      Fix spelling mistake in error message · ee61c8c0
      Ian Gilfillan authored
      ee61c8c0
    • Yuqi Gu's avatar
      MDEV-23495: Refine Arm64 PMULL runtime check in MariaDB · 151fc0ed
      Yuqi Gu authored
      Raspberry Pi 4 supports crc32 but doesn't support pmull (MDEV-23030).
      
      The PR #1645 offers a solution to fix this issue. But it does not consider
      the condition that the target platform does support crc32 but not support PMULL.
      
      In this condition, it should leverage the Arm64 crc32 instruction (__crc32c) and
      just only skip parallel computation (pmull/vmull) rather than skip all hardware
      crc32 instruction of computation.
      
      The PR also removes unnecessary CRC32_ZERO branch in 'crc32c_aarch64' for MariaDB,
      formats the indent and coding style.
      
      Change-Id: I76371a6bd767b4985600e8cca10983d71b7e9459
      Signed-off-by: default avatarYuqi Gu <yuqi.gu@arm.com>
      151fc0ed
    • Marko Mäkelä's avatar
      Merge 10.4 into 10.5 · 0b4ed0b7
      Marko Mäkelä authored
      0b4ed0b7
    • Marko Mäkelä's avatar
      Merge 10.3 into 10.4 · aa6cb7ed
      Marko Mäkelä authored
      aa6cb7ed
    • Marko Mäkelä's avatar
      Merge 10.2 into 10.3 · c277bcd5
      Marko Mäkelä authored
      c277bcd5
    • Marko Mäkelä's avatar
      MDEV-22782 AddressSanitizer race condition in trx_free() · f3160ee4
      Marko Mäkelä authored
      In trx_free() we used to declare the entire trx_t unaccessible
      and then declare that some data members are accessible.
      This involves a race condition with other threads that may concurrently
      access the data members that must remain accessible.
      One type of error is "AddressSanitizer: unknown-crash", whose
      exact cause we have not determined.
      
      Another type of error (reported in MDEV-23472) is "use-after-poison",
      where the reported shadow bytes would in fact be 00, indicating that
      the memory was no longer poisoned. The poison-access-unpoison race
      condition was confirmed by "rr replay".
      
      We eliminate the race condition by invoking MEM_NOACCESS on each
      individual data member of trx_t before freeing the memory to the pool.
      The memory would not be unpoisoned until the pool is freed
      or the memory is being reused for another allocation.
      
      trx_t::free(): Replaces trx_free().
      
      trx_t::active_commit_ordered: Changed to bool, so that MEM_NOACCESS
      can be invoked. Removed some accessor functions.
      
      Pool: Remove all MEM_ instrumentation.
      
      TrxFactory: Move the MEM_ instrumentation from Pool.
      
      TrxFactory::debug(): Removed. Moved to trx_t::free(). Because
      the memory was already marked unaccessible in trx_t::free(), the
      Factory::debug() call in Pool::putl() would be unable to access it.
      
      trx_allocate_for_background(): Replaces trx_create_low().
      
      trx_t::free(): Perform all consistency checks while avoiding
      duplication, and declare most data members unaccessible.
      f3160ee4
    • Andrei Elkin's avatar
      MDEV-23511 shutdown_server 10 times out, causing server kill at shutdown · a19cb388
      Andrei Elkin authored
      Shutdown of mtr tests may be too impatient, esp on CI environment where
      10 seconds of `arg` of `shutdown_server arg` may not be enough for the clean
      shutdown to complete.
      
      This is fixed to remove explicit non-zero timeout argument to
      `shutdown_server` from all mtr tests. mysqltest computes 60 seconds default
      value for the timeout for the argless `shutdown_server` command.
      This policy is additionally ensured with a compile time assert.
      a19cb388
    • Marko Mäkelä's avatar
      MDEV-23526 InnoDB leaks memory for some static objects · d98ccbe1
      Marko Mäkelä authored
      Leaks of some members of statically allocated objects are
      not being reported by AddressSanitizer or Valgrind, but they
      can be reported by implementing SAFEMALLOC instrumentation.
      
      These leaks were identified and original fixes provided
      by Michael Widenius and Vicențiu Ciorbaru.
      d98ccbe1
    • Marko Mäkelä's avatar
      Merge 10.4 into 10.5 · f2739e2a
      Marko Mäkelä authored
      f2739e2a
    • Marko Mäkelä's avatar
    • Marko Mäkelä's avatar
      MDEV-23526 InnoDB leaks memory for some static objects · 688fb630
      Marko Mäkelä authored
      A leak of the contents of fil_system.ssd that was introduced in
      commit 10dd290b (MDEV-17380)
      was caught by implementing SAFEMALLOC instrumentation of operator new.
      I did not try to find out how to make AddressSanitizer or Valgrind
      detect it.
      
      fil_system_t::close(): Clear fil_system.ssd.
      
      The leak was identified and a fix suggested by Michael Widenius
      and Vicențiu Ciorbaru.
      688fb630
    • Marko Mäkelä's avatar
      Merge 10.3 into 10.4 · 2643249d
      Marko Mäkelä authored
      2643249d
    • Marko Mäkelä's avatar
      Merge 10.2 into 10.3 · 9be0b614
      Marko Mäkelä authored
      9be0b614
    • Marko Mäkelä's avatar
      Merge 10.1 into 10.2 · a43faf6b
      Marko Mäkelä authored
      a43faf6b
    • Jan Lindström's avatar
      29d9df16
  13. 20 Aug, 2020 5 commits