summaryrefslogtreecommitdiff
path: root/sql/table.cc
Commit message (Collapse)AuthorAgeFilesLines
* Merge branch '10.1' into 10.2Oleksandr Byelkin2020-02-101-1/+0
|\
| * Merge branch '5.5' into 10.1Oleksandr Byelkin2020-02-101-1/+0
| |\
| | * Clean the comment for `table_f_c unt` parameterAnel Husakovic2020-01-291-1/+0
| | | | | | | | | | | | Deleted with commit: c70a9fa1e3c4
* | | manual merge 10.1->10.2Andrei Elkin2019-11-111-0/+21
|\ \ \ | |/ /
| * | MDEV-20519: Query plan regression with optimizer_use_condition_selectivity > 1Varun Gupta2019-11-071-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The issue here is the wrong estimate of the cardinality of a partial join, the cardinality is too high because the function table_cond_selectivity() returns an absurd number 100 while selectivity cannot be greater than 1. When accessing table t by outer reference t1.a via index we do not perform any range analysis for t. Yet we see TABLE::quick_key_parts[key] and TABLE->quick_rows[key] contain a non-zero value though these should have been remained untouched and equal to 0. Thus real cause of the problem is that TABLE::init does not clean the arrays TABLE::quick_key_parts[] and TABLE::>quick_rows[]. It should have done it because the TABLE structure created for any instance of a table can be reused for many queries.
* | | Part3: MDEV-18156 Assertion `0' failed or `btr_validate_index(index, 0, ↵Sergei Golubchik2019-09-061-0/+2
| | | | | | | | | | | | | | | | | | | | | false)' in row_upd_sec_index_entry or error code 126: Index is corrupted upon DELETE with PAD_CHAR_TO_FULL_LENGTH Don't break compatibility in GA releases. Warn the user, but don't refuse to create a table until 10.5
* | | cleanup: on update default nowSergei Golubchik2019-09-031-9/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | * remove one level of virtual functions * remove redundant checks * remove an if() as the value is always known at compilation time don't pretend that "DEFAULT expr" and "ON UPDATE DEFAULT NOW" are "basically the same thing"
* | | Part2: MDEV-18156 Assertion `0' failed or `btr_validate_index(index, 0, ↵Alexander Barkov2019-09-031-3/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | false)' in row_upd_sec_index_entry or error code 126: Index is corrupted upon DELETE with PAD_CHAR_TO_FULL_LENGTH This patch allows the server to open old tables that have "bad" generated columns (i.e. indexed virtual generated columns, persistent generated columns) that depend on sql_mode, for general things like SELECT, INSERT, DROP, etc. Warning are issued in such cases. Only these commands are now disallowed and return an error: - CREATE TABLE introducing a "bad" generated column - ALTER TABLE introducing a "bad" generated column - CREATE INDEX introdicing a "bad" generated column (i.e. adding an index on a virtual generated column that depends on sql_mode). Note, these commands are allowed: - ALTER TABLE removing a "bad" generate column - ALTER TABLE removing an index from a "bad" virtual generated column - DROP INDEX removing an index from a "bad" virtual generated column but only if the table does not have any "bad" columns as a result.
* | | MDEV-18156 Assertion `0' failed or `btr_validate_index(index, 0, false)' in ↵Alexander Barkov2019-09-031-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | | Merge 10.1 into 10.2Marko Mäkelä2019-07-181-3/+3
|\ \ \ | |/ /
| * | Fix typo open_table_def()Anel Husakovic2019-07-111-3/+3
| | |
| * | imporve clang buildEugene Kosov2019-06-251-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_BUILD_TYPE=Debug Maintainer mode makes all warnings errors. This patch fix warnings. Mostly about deprecated `register` keyword. Too much warnings came from Mroonga and I gave up on it.
* | | MDEV-16222 Assertion `0' failed in row_purge_remove_sec_if_poss_leaf on ↵Aleksey Midenkov2019-07-081-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | table with virtual columns and indexes Cause Stale thd->m_stmt_da->m_sql_errno which is from different invocation. Fix Reset error state before attempt to open table.
* | | Merge 10.1 into 10.2Marko Mäkelä2019-06-121-4/+17
|\ \ \ | |/ /
| * | MDEV-19675 Wrong charset is chosen when opening a pre-4.1 tableAlexander Barkov2019-06-031-2/+3
| | |
| * | MDEV-19653 Add class Sql_cmd_create_tableAlexander Barkov2019-05-311-2/+14
| | |
* | | Merge 10.1 into 10.2Marko Mäkelä2019-05-131-1/+1
|\ \ \ | |/ /
| * | Merge branch '5.5' into 10.1Vicențiu Ciorbaru2019-05-111-1/+1
| |\ \ | | |/
| | * Update FSF AddressVicențiu Ciorbaru2019-05-111-1/+1
| | | | | | | | | | | | * Update wrong zip-code
* | | Merge branch '10.1' into 10.2Oleksandr Byelkin2019-05-041-1/+2
|\ \ \ | |/ /
| * | Merge branch '5.5' into 10.1Sergei Golubchik2019-04-261-1/+2
| |\ \ | | |/
| | * MDEV-15907 ASAN heap-use-after-freeRobert Bindar2019-04-241-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes an invalid read in fill_effective_table_privileges triggered by a grant_version increase between a PREPARE for a statement creating a view from I_S and EXECUTE. A tmp table was created and free'd while preparing the statement, TABLE_LIST::table_name was set to point to the tmp table TABLE_SHARE::table_name which no longer existed after preparing was done. The grant version increase made fill_effective_table_privileges called during EXECUTE to try fetch the updated grant info and this is where the dangling table name was used.
| * | MDEV-14605 Changes to "ON UPDATE CURRENT_TIMESTAMP" fields are notAndrei Elkin2019-01-241-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | always logged properly with binlog_row_image=MINIMAL There are two issues fixed in this commit. The first is an observation of a multi-table UPDATE binlogged in row-format in binlog_row_image=MINIMAL mode. While the UPDATE aims at a table with an ON-UPDATE attribute its binlog after-image misses to record also installed default value. The reason for that turns out missed marking of default-capable fields in TABLE::write_set. This is fixed to mark such fields similarly to 10.2's MDEV-10134 patch (db7edfed17efe6) that introduced it. The marking follows up 93d1e5ce0b841bed's idea to exploit TABLE:rpl_write_set introduced there though, and thus does not mess (in 10.1) with the actual MDEV-10134 agenda. The patch makes formerly arg-less TABLE::mark_default_fields_for_write() to accept an argument which would be TABLE:rpl_write_set. The 2nd issue is extra columns in in binlog_row_image=MINIMAL before-image while merely a packed primary key is enough. The test main.mysqlbinlog_row_minimal always had a wrong result recorded. This is fixed to invoke a function that intended for read_set possible filtering and which is called (supposed to) in all type of MDL, UPDATE including; the test results have gotten corrected. At *merging* from 10.1->10.2 the 1st "main" part of the patch is unnecessary since the bug is not observed in 10.2, so only hunks from sql/sql_class.cc are required.
* | | MDEV-16518 MYSQL57_GENERATED_FIELD: The code in ↵Alexander Barkov2019-04-261-1/+2
| | | | | | | | | | | | TABLE_SHARE::init_from_binary_frm_image() is not safe
* | | Fix for MDEV-18276, typo in error message + all other occurrences of referingChris Calender2019-03-231-1/+1
| | |
* | | MDEV-18083 ASAN heap-use-after-free in ↵Sergei Golubchik2019-02-051-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Field::set_warning_truncated_wrong_value upon inserting into temporary table remove TABLE_SHARE::error_table_name() and TABLE_SHARE::orig_table_name (that was allocated in a wrong memroot in this bug). instead, simply set TABLE_SHARE::table_name correctly.
* | | Merge 10.1 into 10.2Marko Mäkelä2019-01-241-1/+5
|\ \ \ | |/ /
* | | Merge branch '10.1' into 10.2mariadb-10.2.21Sergei Golubchik2018-12-301-4/+4
|\ \ \ | |/ /
| * | Merge branch '10.0' into 10.1Sergei Golubchik2018-12-291-4/+4
| |\ \
| | * | MDEV-17589: Stack-buffer-overflow with indexed varchar (utf8) fieldbb-10.0-varunVarun Gupta2018-12-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | Create a new constant MAX_DATA_LENGTH_FOR_KEY. Replace the value of MAX_KEY_LENGTH to also include the LENGTH and NULL BYTES of a field.
| | * | Backported MDEV-11196(e4d10e09cf31) and MDEV-10360(8a8ba1949bf4) to 10.0Varun Gupta2018-12-191-5/+43
| | | |
* | | | correct table name in CHECK failures during ALTER TABLESergei Golubchik2018-12-201-1/+1
| | | |
* | | | MDEV-17909 Problem by MariaDB Update 10.1.32 -> 10.2.19 (Incorrect ↵Sergei Golubchik2018-12-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | information in file: .frm) use frm_version, not mysql_version when parsing frm In particular, virtual columns are stored according to frm_version. And CHECK TABLE will overwrite mysql_version to the current server version, so it cannot correctly describe frm format.
* | | | MDEV-17831 TRUNCATE TABLE removes ROW_FORMAT=COMPRESSEDMarko Mäkelä2018-11-261-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a table had a KEY_BLOCK_SIZE attribute, but no ROW_FORMAT, it would be created as ROW_FORMAT=COMPRESSED in InnoDB. However, TRUNCATE TABLE would lose the KEY_BLOCK_SIZE attribute and create the table with the innodb_default_row_format (DYNAMIC). This is a regression that was introduced by MDEV-13564. update_create_info_from_table(): Copy also KEY_BLOCK_SIZE.
* | | | MDEV-17349 Assertion `!table || (!table->read_set || ↵Sergei Golubchik2018-11-041-2/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | bitmap_is_set(table->read_set, field_index))' failed on concurrent SELECT and DELETE after RENAME from table with index on virtual column Race condition. field->flags were copied from s->field->flags during field->clone(), early in open_table_from_share(). But s->field->flags were getting their PART_INDIRECT_KEY_FLAG bit much later in TABLE::mark_columns_used_by_virtual_fields() and only once per share. If two threads were executing the code between field->clone() and mark_columns_used_by_virtual_fields() at the same time, only one would get PART_INDIRECT_KEY_FLAG bits in field[].
* | | | MDEV-17065 Crash on SHOW CREATE TABLE with CHECK CONSTRAINTMichael Widenius2018-09-161-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The problem was that the original alias was replaced with a new allocated string, but constraint item's are still pointing to the original alias. Fixed by storing the original alias used when printing constraint in the tables mem_root.
* | | | Merge branch '10.1' into 10.2Oleksandr Byelkin2018-09-141-0/+7
|\ \ \ \ | |/ / /
| * | | Merge branch '11.0' into 10.1Oleksandr Byelkin2018-09-061-0/+21
| |\ \ \ | | |/ /
| | * | MDEV-16757 Memory leak after adding manually min/max statistical dataSergey Vojtovich2018-09-051-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | for blob column Moved delete_stat_values_for_table_share() call to proper place.
| | * | create a reusable function that tells what FK actions can writeSergei Golubchik2018-09-041-0/+6
| | | | | | | | | | | | | | | | Backport of 794f71cbc41
| | * | cleanup: FOREIGN_KEY_INFOSergei Golubchik2018-09-041-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | instead of returning strings for CASCADE/RESTRICT from every storage engine, use enum values Backport of a3614d33e8a
* | | | MDEV-16961 Assertion `!table || (!table->read_set || ↵Sergei Golubchik2018-08-221-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | bitmap_is_set(table->read_set, field_index))' failed upon concurrent DELETE and DDL with virtual blob column After iterating all fields and setting PART_INDIRECT_KEY_FLAG as necessary, TABLE::mark_columns_used_by_virtual_fields() remembers in TABLE_SHARE that this operation was done and need not be repeated. But as the flag is set in TABLE_SHARE, PART_INDIRECT_KEY_FLAG must be set in TABLE_SHARE::field[], not only in TABLE::field[]. Otherwise all new TABLEs opened from this TABLE_SHARE will never have it.
* | | | Merge branch '10.1' into 10.2Oleksandr Byelkin2018-08-031-1/+1
|\ \ \ \ | |/ / /
| * | | Fix gcc 7.3 compiler warnings.Oleksandr Byelkin2018-08-031-1/+1
| | | |
* | | | Merge 10.1 into 10.2Marko Mäkelä2018-08-021-5/+14
|\ \ \ \ | |/ / /
| * | | Merge branch '10.0' into bb-10.1-mergebb-10.1-merge-sanjaOleksandr Byelkin2018-07-191-5/+14
| |\ \ \ | | |/ /
| | * | Merge branch '5.5' into bb-10.0-mergeOleksandr Byelkin2018-07-171-5/+14
| | |\ \ | | | |/
| | | * MDEV-16307: Incorrect results when using BNLH join instead of BNL join with ↵Varun Gupta2018-07-101-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | views In this issue we are using derived_with_keys optimization and we are using these keys to do a hash join which is incorrect. We cannot create keys for dervied tables whose keyparts have types are of BLOB or TEXT type. TEXT or BLOB columns can only be indexed over a specified length.
| | | * Fixed MDEV-16512, crashing on re-execution of failing SPMichael Widenius2018-06-271-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MDEV-16512 Server crashes in find_field_in_table_ref on 2nd execution of SP referring to non-existing field Problem was in the natural join code that it changed TABLE_LIST and Item_fields but didn't restore changed things if things goes wrong and was not able to re-execute after failure. Some of the problems could have been avoided if we would have run fix_fields before doing natural join transformations. Fixed by marking functions complete AFTER they had executed, instead at start. I had also to change some tests that checked if Item_fields are usable. This doesn't fix all known problems, but at least avoids some crashes. What should be done in the near future is to mark the statement in the SP as 'not re-executable' and force a reparse of it on next execution. Reviewer: Sergei Petrunia <psergey@askmonty.org>
* | | | MDEV-16630: Ambiguous error message when check constraint matches table nameAnel Husakovic2018-07-011-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | One can create table with the same name for `field` and `table` `check` constraint. For example: `create table t(a int check(a>0), constraint a check(a>10));` But when inserting new rows same error is always raised. For example with ```insert into t values (-1);``` and ```insert into t values (10);``` same error `ER_CONSTRAINT_FAILED` is obtained and it is not clear which constraint is violated. This patch solve this error so that in case if field constraint is violated the first parameter in the error message is `table.field_name` and if table constraint is violated the first parameter in error message is `constraint_name`.
View Lorry Controller Status