1
0
mirror of https://github.com/MariaDB/server.git synced 2025-08-07 00:04:31 +03:00
Commit Graph

11 Commits

Author SHA1 Message Date
Nikita Malyavin
1f5ca66e53 MDEV-26866 FOREIGN KEY…SET NULL corrupts an index on a virtual column
The initial test case for MySQL Bug #33053297 is based on
mysql/mysql-server@27130e2507.

innobase_get_field_from_update_vector is not a suitable function to fetch
updated row info, as well as parent table's update vector is not always
suitable. For instance, in case of DELETE it contains undefined data.

castade->update vector seems to be good enough to fetch all base columns
update data, and besides faster, and less error-prone.
2021-10-28 07:32:27 +03:00
Marko Mäkelä
173e562dc2 MDEV-26228 ASAN heap-use-after-free with ON UPDATE CASCADE
In commit 83d2e0841e (MDEV-24041)
we failed to notice that in addition to the bug with
DELETE and ON DELETE CASCADE, there is another bug with
UPDATE and ON UPDATE CASCADE.

row_ins_foreign_fill_virtual(): Use the correct memory heap
for everything that will be reachable from the cascade->update
that we return to the caller.

Note: It is correct to use the shorter-lived cascade->heap for
rec_get_offsets(), because that memory will be abandoned when
row_ins_foreign_fill_virtual() returns.
2021-07-23 17:20:57 +03:00
Thirunarayanan Balathandayuthapani
82d39d4374 MDEV-24491 db_name mismatch happens during virtual column computation
Database name mismatch happens while opening the table for
virtual column computation. Because table_name_parse() returns
the length of database and table name before converting the
filename to table name. This issue is caused by
commit 8b0d4cff07 (MDEV-15855).
Fix should be that table_name_parse() should return the length of
database and table name after converting the filename to table name.

Reviewed-by: Marko Mäkelä
2021-01-19 16:18:37 +05:30
Nikita Malyavin
83d2e0841e MDEV-24041 Generated column DELETE with FOREIGN KEY crash InnoDB
row_upd_clust_step() calls row_upd_del_mark_clust_rec() which would
allocate some memory in row_ins_foreign_fill_virtual(). Then,
row_upd_store_row() would access the allocated memory, but only after
potentially freeing that memory by invoking mem_heap_empty(),
leading to ASAN heap-use-after-free diagnostics.

row_ins_foreign_fill_virtual(): Use a more appropriate memory heap with a
longer lifetime.
2020-12-18 20:17:45 +10:00
Thirunarayanan Balathandayuthapani
923ecbdfef MDEV-23387 dict_load_foreign() fails to load the table during alter
Problem:
=======
 InnoDB allows virtual index to be referenced index in foreign key
relations. While dropping the virtual column, Inplace alter does
allow the table to be closed and open it using table name to
update dict_table_t::v_cols. While loading the table, it doesn't
allow any error to be ignored. InnoDB can't find the referenced
virtual index and fails to load the table during Inplace alter.

Solution:
=========
  During inplace alter, ignore the foreign key error while loading
the table.

Reviewed-by: Marko Mäkelä
2020-10-19 19:36:00 +05:30
Nikita Malyavin
ae8ff3a067 MDEV-20396 Server crashes after DELETE with SEL NULL Foreign key and a
virtual column in index

Problem:
row_ins_foreign_fill_virtual was unconditionally set virtual fields to NULL
even though the field is not a part of a foreign key
(but a part of an index)

Solution:
The new virtual value should be computed with regard to cascade updates.
2020-09-14 18:08:56 +10:00
Sergei Golubchik
676f43da3a cleanup: don't ---replace_regex /#sql-.*/#sql-temporary/
no longer needed
2019-02-05 01:34:17 +01:00
Marko Mäkelä
4fde1361a6 MDEV-15553 Assertion failed in dict_table_get_col_name
dict_foreign_qualify_index(): Avoid a redundant and harmful
computation of col_name of a virtual column. This fixes the
assertion failure.

dict_foreign_push_index_error(): Do not call dict_table_get_col_name()
on a virtual column. (It is unclear if this condition is actually
reachable.)
2018-04-05 15:01:17 +03:00
Thirunarayanan Balathandayuthapani
a6adf567fd Bug #23533396 ASSERTION !M_PREBUILT->TRX->CHECK_FOREIGNS
Analysis:
========
A foreign key constraint cannot reference a secondary index defined
on a generated virtual column. While adding new index/drop existing
column, server internally drops the internal foreign key index and
it leads to choose the virtual secondary index as foreign key index.
But innodb doesn't allow foreign key constraint reference to
secondary virtual index.

Fix:
===
Allow foreign key constraint refer to secondary index defined on
a generated virutal column.

Reviewed-by: Jimmy Yang<jimmy.yang@oracle.com>
RB: 13586
2017-04-26 23:03:27 +03:00
Nirbhay Choubey
8b2e642aa2 MDEV-7635: Update tests to adapt to the new default sql_mode 2017-02-10 06:30:42 -05:00
Sergei Golubchik
1cae1af6f9 MDEV-5800 InnoDB support for indexed vcols
* remove old 5.2+ InnoDB support for virtual columns
  * enable corresponding parts of the innodb-5.7 sources
  * copy corresponding test cases from 5.7
  * copy detailed Alter_inplace_info::HA_ALTER_FLAGS flags from 5.7
     - and more detailed detection of changes in fill_alter_inplace_info()
  * more "innodb compatibility hooks" in sql_class.cc to
     - create/destroy/reset a THD (used by background purge threads)
     - find a prelocked table by name
     - open a table (from a background purge thread)

  * different from 5.7:
    - new service thread "thd_destructor_proxy" to make sure all THDs are
      destroyed at the correct point in time during the server shutdown
    - proper opening/closing of tables for vcol evaluations in
       + FK checks (use already opened prelocked tables)
       + purge threads (open the table, MDLock it, add it to tdc, close
         when not needed)
    - cache open tables in vc_templ
    - avoid unnecessary allocations, reuse table->record[0] and table->s->default_values
    - not needed in 5.7, because it overcalculates:
      + tell the server to calculate vcols for an on-going inline ADD INDEX
      + calculate vcols for correct error messages

  * update other engines (mroonga/tokudb) accordingly
2016-12-12 20:27:42 +01:00