mariadb

Tree: 4902b0fdc9

Author	SHA1	Message	Date
Nikita Malyavin	22709897b0	MDEV-20154 Assertion `len <= col->len \| ...` failed in row_merge_buf_add 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 `12614af1fe`. 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.	4 years ago
Thirunarayanan Balathandayuthapani	7d591cf850	MDEV-24713 Assertion `dict_table_is_comp(index->table)' failed in row_merge_buf_add() - During online alter conversion from compact to redundant, virtual column field length already set during innobase_get_computed_value(). Skip the char(n) check for virtual column in row_merge_buf_add()	4 years ago
Thirunarayanan Balathandayuthapani	7229107e3e	MDEV-25872 InnoDB: Assertion failure in row_merge_read_clustered_index upon ALTER on table with indexed virtual columns - InnoDB fails to check DB_COMPUTE_VALUE_FAILED error in row_merge_read_clustered_index() and wrongly asserts that the buffer shouldn't be ran out of memory. Alter table should give warning when the column value is being truncated.	4 years ago
Nikita Malyavin	a3d66090c7	MDEV-18366 Crash on SELECT on a table with indexed virtual columns The problem was in improper error handling behavior in `row_upd_build_difference_binary`: `innobase_free_row_for_vcol` wasn't called. To eliminate this problem in all potential places, a refactoring has been made: * class ib_vcol_row is added. It owns VCOL_STORAGE and heap and maintains it in RAII manner * all innobase_allocate_row_for_vcol/innobase_free_row_for_vcol pairs are substituted with ib_vcol_row usage * row_merge_buf_add is only left untouched because it doesn't own vheap passed as an argument * innobase_allocate_row_for_vcol does not allocate VCOL_STORAGE anymore and accepts it as an argument -- this reduces a number of memory allocations * move rec_printer out of `#ifndef DBUG_OFF` and mark it cold	5 years ago
Alexander Barkov	dc719597ee	MDEV-18156 Assertion `0' failed or `btr_validate_index(index, 0, false)' in row_upd_sec_index_entry or error code 126: Index is corrupted upon DELETE with PAD_CHAR_TO_FULL_LENGTH This change takes into account a column's GENERATED ALWAYS AS expression dependcy on sql_mode's PAD_CHAR_TO_FULL_LENGTH and NO_UNSIGNED_SUBTRACTION flags. Indexed virtual columns as well as persistent generated columns are now not allowed to have such dependencies to avoid inconsistent data or index files on sql_mode changes. So an error is now returned in cases like this: CREATE OR REPLACE TABLE t1 ( a CHAR(5), v VARCHAR(5) AS (a) PERSISTENT -- CHAR->VARCHAR or CHAR->TEXT = ERROR ); Functions RPAD() and RTRIM() can now remove dependency on PAD_CHAR_TO_FULL_LENGTH. So this can be used instead: CREATE OR REPLACE TABLE t1 ( a CHAR(5), v VARCHAR(5) AS (RTRIM(a)) PERSISTENT ); Note, unlike CHAR->VARCHAR and CHAR->TEXT this still works, not RPAD(a) is needed: CREATE OR REPLACE TABLE t1 ( a CHAR(5), v CHAR(5) AS (a) PERSISTENT -- CHAR->CHAR is OK ); More sql_mode flags may affect values of generated columns. They will be addressed separately. See comments in sql_mode.h for implementation details.	6 years ago
Marko Mäkelä	7930ab7e33	Comment out the statement that triggers MDEV-18366	7 years ago
Marko Mäkelä	64678ca506	Bug #22990029 : Add a test case	7 years ago
Marko Mäkelä	31366c6c93	MDEV-17548 Incorrect access to off-page column for indexed virtual column row_build_index_entry_low(): ext does not contain virtual columns. row_upd_store_v_row(): Copy virtual column values This is based on the following fix in MySQL 5.7.24: commit `4ec2158bec` Author: Sachin Agarwal <sachin.z.agarwal@oracle.com> Date: Fri Aug 24 14:44:13 2018 +0530 Bug #27968952 INNODB CRASH/CORRUPTION WITH TEXT PREFIX INDEXES Problem: There are two problems: 1. If there is one secondary index on extenally stored column and another seconday index on virtual column (whose base column is not externally stored). then while updating seconday index on vitrual column, virtual column data is replaced by externally stoared column. 2. In row update operation, node->row contains shallow copy of virtual data fields. While building an update vector containing all the fields to be modified, compute virtual column. which may causes change in virtual data fields in node->row. In both the above cases, while updating seconday index on virtual column, couldn't find the row and hit an explicite assert inside ROW_NOT_FOUND. Fix: 1. Added check if column is virtual then its ext flag should be ZERO and virtual column data will not be replaced by offset column data. 2. Deep copy of virtual data fields for node->row. RB: #20382 Reviewed by : Jimmy.Yang@oracle.com	7 years ago
Marko Mäkelä	2b24b04220	Bug 27122803 - BACKPORT FIX FOR BUG 25899959 TO MYSQL-5.7 Merge a test case and a code change from MySQL 5.7.22. There was no commit message, but a test case was included. `d3ec326bcd` There is no Bug 25899959 mentioned in the MySQL 8.0.11 history. Based on the number, it should have been filed before August 2017. Maybe it was initially fixed in a not-yet-public MySQL 9.0 branch? The code change differs from MySQL 5.7, because the mbminmaxlen were split in MariaDB in MDEV-7049.	8 years ago
Marko Mäkelä	7a9fee9853	MDEV-13568 gcol.innodb_virtual_debug_purge failed in buildbot with wrong result The InnoDB background tasks can modify tables while LOCK TABLES...WRITE is in effect. The purge of InnoDB history always worked like this in MariaDB, but in MySQL 5.7 it sometimes yields to LOCK TABLES. Also, make gcol.innodb_virtual_index run the purge for an UPDATE before DROP TABLE is executed.	8 years ago
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	9 years ago

11 Commits (4902b0fdc91cc6dc169dd2322daf966a2eeafdd8)