Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-16417 Store Foreign Key metadata outside of InnoDB
  3. MDEV-21052

InnoDB foreign key refactoring for TABLE_SHARE::foreign_keys

    XMLWordPrintable

Details

    Description

      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".

      Attachments

        Issue Links

          Activity

            People

              midenok Aleksey Midenkov
              midenok Aleksey Midenkov
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

                Created:
                Updated:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.