summaryrefslogtreecommitdiff
path: root/mysql-test/suite/vcol/r
Commit message (Collapse)AuthorAgeFilesLines
* MDEV-17349 Assertion `!table || (!table->read_set || ↵Sergei Golubchik2018-11-041-0/+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-16961 Assertion `!table || (!table->read_set || ↵Sergei Golubchik2018-08-221-0/+10
| | | | | | | | | | | | | | 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.2Sergei Golubchik2018-06-211-0/+10
|\
| * Merge remote-tracking branch 'origin/10.0' into 10.1Alexander Barkov2018-06-191-0/+10
| |\
| | * Merge remote-tracking branch 'origin/5.5' into 10.0Alexander Barkov2018-06-191-0/+10
| | |\
| | | * MDEV-15834 The code in TABLE_SHARE::init_from_binary_frm_image() is not safeAlexander Barkov2018-06-191-0/+10
| | | |
* | | | MDEV-15114 ASAN heap-use-after-free in mem_heap_dup or ↵Monty2018-06-191-0/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | dfield_data_is_binary_equal The bug was that innobase_get_computed_value() trashed record[0] and data in Field_blob::value Fixed by using a record on the heap for innobase_get_computed_value() Reviewer: Marko Mäkelä
* | | | Add PART_INDIRECT_KEY_FLAGMonty2018-06-191-0/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is to mark that a field is indirectly part of a key, which simplifes checking if we need to have this field up to date to evaluate a key. For example: CREATE TABLE t1 (a int, b int as (a) virtual, c int as (b) virtual, index(c)) would mark a and b with PART_INDIRECT_KEY_FLAG. c is marked with PART_KEY_FLAG as before.
* | | | MDEV-15243 Crash with virtual fields and row based binary loggingMonty2018-05-243-0/+443
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The cause of this was several different bugs: - When using binary logging with binlog_row_image=FULL the all bits in read_set was set, which caused a different (wrong) pattern for marking vcol_set. - TABLE::mark_virtual_columns_for_write() didn't in all cases mark vcol_set with the vcol_field. - TABLE::update_virtual_fields() has to update all vcol fields on REPLACE if binary logging with FULL is used. - VCOL_UPDATE_INDEXED should update all vcol fields part of an index that was not updated by VCOL_UPDATE_FOR_READ - max_row_length() calculated length of NULL and not used fields. This didn't cause any crash, but used more memory than needed.
* | | | MDEV-15626 Assertion on update virtual column in partitioned tableSergei Golubchik2018-05-101-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | table.cc: virtual columns must be computed for INSERT, if they're part of the partitioning expression. this change broke gcol.gcol_partition_innodb. fix CHECK TABLE for partitioned tables and vcols. sql_partition.cc: mark prerequisite base columns in full_part_field_set ha_partition.cc initialize vcol_set accordingly
* | | | Ensure that table->vcol_set is properly restored if usedMonty2018-01-011-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Code in QUICK_RANGE_SELECT::init_ror_merged_scan() could theoretically have caused crashes if this was ever called from an update or delete This also found a bug in the vcol/range.result. file.
* | | | Merge branch '10.1' into 10.2Sergei Golubchik2017-10-241-1/+20
|\ \ \ \ | |/ / /
| * | | Merge branch '10.0' into 10.1Sergei Golubchik2017-10-221-1/+20
| |\ \ \ | | |/ /
| | * | Merge branch '5.5' into 10.0Sergei Golubchik2017-10-181-0/+19
| | |\ \ | | | |/
| | | * MDEV-11819 NO_ZERO_IN_DATE: Incorrect generated column valueAlexander Barkov2017-10-061-0/+19
| | | |
| * | | MDEV-10880: Assertions `keypart_map' or `prebuilt->search_tuple->n_fields > ↵Oleksandr Byelkin2017-06-232-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | 0' fail on DISTINCT and GROUP BY constant add_group_and_distinct_keys() should take into account JOIN::simple_group.
* | | | MDEV-13708 Crash with indexed virtual columns and FK cascading deletesSergei Golubchik2017-09-181-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | InnoDB was too eager to forget the open table (m_mysql_table=NULL) and that caused it to try to open a table which was opened by the user not FK-prelocked. The server didn't expect that. After fixing this, it crashed in gcol.innodb_virtual_fk test, trying to compute virtual columns for a table that didn't have them. Because row_upd_store_row() was deleting a row from node->table, while computing virtual columns in thr->prebuilt->m_mysql_table. Which wasn't necessarily the same table, and might've not even had virtual columns, even if node->table did.
* | | | MDEV-13623 Assertion `!table || (!table->read_set || ↵Sergei Golubchik2017-09-181-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | bitmap_is_set(table->read_set, field_index))' failed in virtual longlong Field_long::val_int multi-update first runs a select to find affected rows, then performs a separate update step. On the second step WITH CHECK OPTION rows are read with rnd_read, but the first step might've been done with keyread. keyread over indexed virtual columns only reads the column's value, not dependent base columns. This is reflected in the read_set too. But on the rnd_read step base columns must be read - thus we need to update the read_set before doing updates.
* | | | bugfix: TIME_FORMAT() should be ok in stored generated columnsSergei Golubchik2017-09-181-0/+15
| | | |
* | | | bugfix: TIME_FORMAT() allowed some non-time format specifiersSergei Golubchik2017-09-181-4/+4
| | | | | | | | | | | | | | | | it contradicted the manual and was inconsistent
* | | | MDEV-13435 Crash when selecting virtual columns generated using JSON functionsSergei Golubchik2017-08-141-0/+9
| | | | | | | | | | | | | | | | | | | | don't allocate memory on thd->mem_root in every fix_fields(), do it once and reuse.
* | | | MDEV-13209 Cross-database operation with virtual columns failsSergei Golubchik2017-07-051-0/+17
| | | | | | | | | | | | | | | | | | | | if we don't need to print field's table name, we surely don't need to print field's db name either
* | | | MDEV-12936 upgrade to 10.2.6 failed upon tables with virtual columnsSergei Golubchik2017-07-051-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | when opening 10.1- table that has virtual columns: 1. don't error out if it has vcols over autoinc columns. just issue a warning. 2. set vcol type properly 3. in innodb: use table->s->stored_fields instead of table->s->fields, because that's what was stored in innodb data dictionary
* | | | vcol.wrong_arena fails in fulltestSergei Golubchik2017-04-011-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | vcols in the table definition are intentionaly bad and produce warnings when a table is opened. In some cases (depending on the TDC/TC state as left by earlier tests) a table might be opened in the middle of the test, resulting in spurious warnings. Suppress them. Also, don't run main.mdev-504 for ps-protocol at all (instead of disabling ps-protocol inside the test, but still running the test)
* | | | Merge branch '10.1' into 10.2Sergei Golubchik2017-03-301-0/+109
|\ \ \ \ | |/ / /
| * | | Merge 10.0 into 10.1Marko Mäkelä2017-03-091-0/+109
| |\ \ \ | | |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | Also, implement MDEV-11027 a little differently from 5.5 and 10.0: recv_apply_hashed_log_recs(): Change the return type back to void (DB_SUCCESS was always returned). Report progress also via systemd using sd_notifyf().
| | * | Merge branch '5.5' into 10.0Vicențiu Ciorbaru2017-03-031-0/+109
| | |\ \ | | | |/
| | | * MDEV-11525 Assertion `cp + len <= buff + buff_size' failed in ↵Sergei Golubchik2017-02-271-0/+109
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | JOIN_CACHE::write_record_data Workaround for join_cache + index on vcols + keyread bug. Initialize the record to avoid caching garbage in non-read fields. A proper fix (do not cache non-read fields at all) is done in 10.2 in commits 5d7607f340f..8d99166c697
* | | | MDEV-11605 Assertion `(longlong) thd->status_var.local_memory_used >= 0 || ↵Sergei Golubchik2017-03-291-0/+134
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | !debug_assert_on_not_freed_memory' failed in my_malloc_size_cb_func MyISAM in compute_vcols() - which is used only in mi_check code - was computing indexed vcols into an internally allocated buffer (not record[0]) and the buffer was calculated to be long enough to fit every keyseg (a keyseg knows where its value in a record buffer is and the length of the value). This logic didn' work for prefix keys, because the keyseg length is the length of a prefix, but the record buffer needs to fit the complete value of a vcol. In this bug MyISAM was writing a 2K varchar into a buffer too short. Also it didn't work for repair-with-keycache, because that code recalculats all vcols, not only indexed ones. So, the buffer size (MYISAM_SHARE::vreclength) should include all vcols' full lengths. But it was calculated in mi_open and low-level MyISAM code has no knowledge of vcols. As a fix we now recalculate MYISAM_SHARE::vreclength in ha_myisam::setup_vcols_for_repair() which is always called before compute_vcols().
* | | | MDEV-11704 InnoDB: Failing assertion: dfield_is_null(dfield2) || dfield2->dataSergei Golubchik2017-02-131-0/+11
| | | | | | | | | | | | | | | | | | | | relax innodb assertion, because Field_blob::store() clearly says that a data pointer can be zero if the length is zero.
* | | | MDEV-11604 Assertion `!check_datetime_range(ltime)' failed in ↵Sergei Golubchik2017-02-131-0/+33
| | | | | | | | | | | | | | | | TIME_to_longlong_datetime_packed
* | | | MDEV-11640 gcol.gcol_select_myisam fails in buildbot on PowerSergei Golubchik2017-02-131-0/+109
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | JOIN_CACHE's were initialized in check_join_cache_usage() from make_join_readinfo(). After that make_join_readinfo() was looking whether it's possible to use keyread. Later, after make_join_readinfo(), optimizer decided whether to use filesort. And even later, at the execution time, from join_read_first(), keyread was actually enabled. The problem is, that if a query uses a vcol, base columns that it depends on are automatically added to the read_set - because they're needed to calculate the vcol. But if we're doing keyread, vcol is taken from the index, not calculated, and base columns do not need to be in the read set (even should not be - as they aren't getting values). The bug was that JOIN_CACHE used read_set with base columns, they were not read because of keyread, so it was caching garbage. So read_set is only known after the keyread was decided. And after the filesort was decided, as filesort doesn't use keyread. But check_join_cache_usage() needs to be done in make_join_readinfo(), as the code below depends on these checks, Fix: keep JOIN_CACHE checks where they were, but move initialization down to the very end of JOIN::optimize_inner. If keyread was enabled, update the read_set to include only columns that are part of the index. Copy the keyread logic from join_read_first() to happen at optimize time.
* | | | MDEV-11750 Assertion `vfield' failed in TABLE::update_virtual_fields after ↵Sergei Golubchik2017-02-131-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | crash recovery on corrupted MyISAM table Adjust the length of the BIT field (same as in _mi_put_key_in_record())
* | | | Merge branch 'bb-10.2-serg-merge' into 10.2Sergei Golubchik2017-02-114-2/+88
|\ \ \ \
| * \ \ \ Merge branch '10.1' into 10.2Sergei Golubchik2017-02-104-2/+88
| |\ \ \ \ | | |/ / /
| | * | | Merge branch '10.0' into 10.1mariadb-10.1.21Sergei Golubchik2017-01-171-0/+61
| | |\ \ \ | | | |/ /
| | | * | Merge branch '5.5' into 10.0Sergei Golubchik2017-01-171-0/+61
| | | |\ \ | | | | |/
| | | | * bugfix: Item_func_min_max stored thd internallySergei Golubchik2017-01-151-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It was used for get_datetime_value() and for thd->is_error(). But in fact, get_datetime_value() never used thd argument, because the cache ptr argument was NULL. And thd->is_error() check was not needed at that place at all.
| | | | * bugfix: cmp_item_row::alloc_comparators() allocated on the wrong arenaSergei Golubchik2017-01-151-6/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | it used current_thd->alloc() and allocated on the thd's execution arena, not on table->expr_arena. Remove THD::arena_for_cached_items that is temporarily set in update_virtual_fields(), and replaces THD arena in get_datetime_value(). Instead set THD arena to table->expr_arena for the whole duration of update_virtual_fields()
| | | | * MDEV-9690 concurrent queries with virtual columns crash in temporal codeSergei Golubchik2017-01-151-0/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Item_func_le included Arg_comparator. Arg_comparator remembered the current_thd during fix_fields and used that value during execution to allocate Item_cache in get_datetime_value(). But for vcols fix_fields and val_int can happen in different threads. Same bug for Item_func_in using in_datetime or cmp_item_datetime, both also remembered current_thd at fix_fields() to use it later for get_datetime_value(). As a fix, these objects no longer remember the current_thd, and get_datetime_value() uses current_thd at run time. This should not increase the number of current_thd calls much, as Item_cache is created only once anyway.
| | * | | Merge branch '10.0' into 10.1Vicențiu Ciorbaru2017-01-163-2/+21
| | |\ \ \ | | | |/ /
| | | * | Merge branch '5.5' into 10.0Vicențiu Ciorbaru2017-01-143-2/+21
| | | |\ \ | | | | |/
| | | | * MDEV-11527 Virtual columns do not get along well with NO_ZERO_DATESergei Golubchik2017-01-121-0/+7
| | | | | | | | | | | | | | | | | | | | don't check defaults for vcols
| | | | * MDEV-11706 Assertion `is_stat_field || !table || (!table->write_set || ↵Sergei Golubchik2017-01-112-2/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | bitmap_is_set(table->write_set, field_index) || (table->vcol_set && bitmap_is_set(table->vcol_set, field_index)))' failed in Field_time::store_TIME_with_warning vcols and triggers. Revert 094f4cf77890c5a747a57cf2bed149b0b6933507, backport the correct fix (Table_triggers_list::mark_fields_used() not marking vcols) from 10.2.
* | | | | MDEV-7635: Update tests to adapt to the new default sql_modeNirbhay Choubey2017-02-1011-91/+123
|/ / / /
* | | | MDEV-11597 Assertion when doing select from virtual column with impossible valueMonty2017-01-112-0/+457
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Changed error handlers interface so that they can change error level in the handler - Give warnings and errors when calculating virtual columns - On insert/update error is fatal in strict mode. - SELECT and DELETE will only give a warning if a virtual field generates an error - Added VCOL_UPDATE_FOR_DELETE and VCOL_UPDATE_INDEX_FOR_REPLACE to be able to easily detect in update_virtual_fields() if we should use an error handler to mask errors or not.
* | | | MDEV-11606 Server crashes in mi_make_key / sort_key_readMonty2017-01-111-116/+154
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem was that one internal record buffer in MYISAM was not big enough to handle virtual fields. Fixed by extending buffer. Fixed test case to 79 characters
* | | | MDEV-11737 Failing assertion: block->magic_n == MEM_BLOCK_MAGIC_NMonty2017-01-111-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Issue was that the m_prebuilt array was reused without resetting a counter, which caused a memory overrun. Adjusted test case to 79 characters
* | | | MDEV-11598 Assertion `!table || (!table->read_set || ↵Monty2017-01-112-0/+94
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | bitmap_is_set(table->read_set, field_index))' failed Found and fixed 2 problems: - Filesort addon fields didn't mark virtual columns properly - multi-range-read calculated vcol bitmap but was not using it. This caused wrong vcol field to be calculated on read, which caused the assert.
* | | | New simpler bugfix for UPDATE and virtual BLOBsMonty2017-01-113-2/+360
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When updating a table with virtual BLOB columns, the following might happen: - an old record is read from the table, it has no virtual blob values - update_virtual_fields() is run, vcol blob gets its value into the record. But only a pointer to the value is in the table->record[0], the value is in Field_blob::value String (but it doesn't have to be! it can be in the record, if the column is just a copy of another columns: ... b VARCHAR, c BLOB AS (b) ...) - store_record(table,record[1]), old record now is in record[1] - fill_record() prepares new values in record[0], vcol blob is updated, new value replaces the old one in the Field_blob::value - now both record[1] and record[0] have a pointer that points to the *new* vcol blob value. Or record[1] has a pointer to nowhere if Field_blob::value had to realloc. To fix this I have introduced a new String object 'read_value' in Field_blob. When updating virtual columns when a row has been read, the allocated value is stored in 'read_value' instead of 'value'. The allocated blobs for the new row is stored in 'value' as before. I also made, as a safety precaution, the insert delayed handling of blobs more general by using value to store strings instead of the record. This ensures that virtual functions on delayed insert should work in as in the case of normal insert. Triggers are now properly updating the read, write and vcol maps for used fields. This means that we don't need VCOL_UPDATE_FOR_READ_WRITE anymore and there is no need for any other special handling of triggers in update_virtual_fields(). To be able to test how many times virtual fields are invoked, I also relaxed rules that one can use local (@) variables in DEFAULT and non persistent virtual field expressions.
View Lorry Controller Status