summaryrefslogtreecommitdiff
path: root/sql/table.h
Commit message (Collapse)AuthorAgeFilesLines
* Merge branch 'bb-10.5-release' into bb-10.6-release10.6-halfmergeOleksandr Byelkin2021-02-161-19/+19
|\
| * Merge branch 'bb-10.4-release' into bb-10.5-releaseSergei Golubchik2021-02-151-19/+19
| |\
| | * Merge branch 'bb-10.3-release' into bb-10.4-releaseSergei Golubchik2021-02-121-19/+19
| | |\ | | | | | | | | | | | | | | | | Note, the fix for "MDEV-23328 Server hang due to Galera lock conflict resolution" was null-merged. 10.4 version of the fix is coming up separately
| | | * MDEV-17556 Assertion `bitmap_is_set_all(&table->s->all_set)' failedNikita Malyavin2021-01-271-19/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The assertion failed in handler::ha_reset upon SELECT under READ UNCOMMITTED from table with index on virtual column. This was the debug-only failure, though the problem is mush wider: * MY_BITMAP is a structure containing my_bitmap_map, the latter is a raw bitmap. * read_set, write_set and vcol_set of TABLE are the pointers to MY_BITMAP * The rest of MY_BITMAPs are stored in TABLE and TABLE_SHARE * The pointers to the stored MY_BITMAPs, like orig_read_set etc, and sometimes all_set and tmp_set, are assigned to the pointers. * Sometimes tmp_use_all_columns is used to substitute the raw bitmap directly with all_set.bitmap * Sometimes even bitmaps are directly modified, like in TABLE::update_virtual_field(): bitmap_clear_all(&tmp_set) is called. The last three bullets in the list, when used together (which is mostly always) make the program flow cumbersome and impossible to follow, notwithstanding the errors they cause, like this MDEV-17556, where tmp_set pointer was assigned to read_set, write_set and vcol_set, then its bitmap was substituted with all_set.bitmap by dbug_tmp_use_all_columns() call, and then bitmap_clear_all(&tmp_set) was applied to all this. To untangle this knot, the rule should be applied: * Never substitute bitmaps! This patch is about this. orig_*, all_set bitmaps are never substituted already. This patch changes the following function prototypes: * tmp_use_all_columns, dbug_tmp_use_all_columns to accept MY_BITMAP** and to return MY_BITMAP * instead of my_bitmap_map* * tmp_restore_column_map, dbug_tmp_restore_column_maps to accept MY_BITMAP* instead of my_bitmap_map* These functions now will substitute read_set/write_set/vcol_set directly, and won't touch underlying bitmaps.
* | | | Merge 10.5 into 10.6Marko Mäkelä2021-01-111-1/+5
|\ \ \ \ | |/ / /
| * | | Merge 10.4 into 10.5Marko Mäkelä2021-01-111-1/+5
| |\ \ \ | | |/ /
| | * | Merge 10.3 into 10.4Marko Mäkelä2021-01-111-1/+5
| | |\ \ | | | |/
| | | * Merge 10.2 into 10.3 (except MDEV-17556)Marko Mäkelä2021-01-111-1/+5
| | | |\ | | | | | | | | | | | | | | | | | | | | | | | | | The fix of MDEV-17556 (commit e25623e78a3efde05e30070dc7362f8dc0d8c459 and commit 61a362c9493df63dc588fcb71409537ae56ab9c8) has been omitted due to conflicts and will have to be applied separately later.
| | | | * MDEV-17556 Assertion `bitmap_is_set_all(&table->s->all_set)' failedNikita Malyavin2021-01-081-19/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The assertion failed in handler::ha_reset upon SELECT under READ UNCOMMITTED from table with index on virtual column. This was the debug-only failure, though the problem is mush wider: * MY_BITMAP is a structure containing my_bitmap_map, the latter is a raw bitmap. * read_set, write_set and vcol_set of TABLE are the pointers to MY_BITMAP * The rest of MY_BITMAPs are stored in TABLE and TABLE_SHARE * The pointers to the stored MY_BITMAPs, like orig_read_set etc, and sometimes all_set and tmp_set, are assigned to the pointers. * Sometimes tmp_use_all_columns is used to substitute the raw bitmap directly with all_set.bitmap * Sometimes even bitmaps are directly modified, like in TABLE::update_virtual_field(): bitmap_clear_all(&tmp_set) is called. The last three bullets in the list, when used together (which is mostly always) make the program flow cumbersome and impossible to follow, notwithstanding the errors they cause, like this MDEV-17556, where tmp_set pointer was assigned to read_set, write_set and vcol_set, then its bitmap was substituted with all_set.bitmap by dbug_tmp_use_all_columns() call, and then bitmap_clear_all(&tmp_set) was applied to all this. To untangle this knot, the rule should be applied: * Never substitute bitmaps! This patch is about this. orig_*, all_set bitmaps are never substituted already. This patch changes the following function prototypes: * tmp_use_all_columns, dbug_tmp_use_all_columns to accept MY_BITMAP** and to return MY_BITMAP * instead of my_bitmap_map* * tmp_restore_column_map, dbug_tmp_restore_column_maps to accept MY_BITMAP* instead of my_bitmap_map* These functions now will substitute read_set/write_set/vcol_set directly, and won't touch underlying bitmaps.
| | | | * MDEV-23033: All slaves crash once in ~24 hours and loop restart with signal 11Sujatha2021-01-041-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: ======= Upon deleting or updating a row in a parent table (with primary key), if the child table has virtual column and an associated key with ON UPDATE CASCADE/ON DELETE CASCADE, it will result in slave crash. Analysis: ======== Tables which are related through foreign key require prelocking similar to triggers. i.e If a table has triggers/foreign keys we should add all tables and routines used by them to the prelocking set. This prelocking happens during 'open_and_lock_tables' call. Each table being opened is checked for foreign key references. If foreign key reference exists then the child table is opened and it is linked to the table_list. Upon any modification to parent table its corresponding child tables are retried from table_list and they are updated accordingly. This prelocking work fine on master. On slave prelocking works for following cases. - Statement/mixed based replication - In row based replication when trigger execution is enabled through 'slave_run_triggers_for_rbr=YES/LOGGING/ENFORCE' Otherwise it results in an assert/crash, as the parent table will not find the corresponding child table and it will be NULL. Dereferencing NULL pointer leads to slave server exit. Fix: === Introduce a new 'slave_fk_event_map' flag similar to 'trg_event_map'. This flag will ensure that when foreign key is enabled in row based replication all the parent and child tables are prelocked, so that parent is able to locate the child table. Note: This issue is specific to slave, hence only slave needs to be upgraded.
* | | | | Merge 10.5 into 10.6mariadb-10.5.7bb-10.6-georg10.6-vatuMarko Mäkelä2020-11-031-1/+2
|\ \ \ \ \ | |/ / / /
| * | | | Merge 10.4 into 10.5Marko Mäkelä2020-11-031-1/+2
| |\ \ \ \ | | |/ / /
| | * | | Merge 10.3 into 10.4Marko Mäkelä2020-11-031-1/+2
| | |\ \ \ | | | |/ /
| | | * | Merge 10.2 into 10.3Marko Mäkelä2020-11-021-1/+2
| | | |\ \ | | | | |/
| | | | * MDEV-22387: Do not violate __attribute__((nonnull))Marko Mäkelä2020-11-021-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This follows up commit commit 94a520ddbe39ae97de1135d98699cf2674e6b77e and commit 7c5519c12d46ead947d341cbdcbb6fbbe4d4fe1b. After these changes, the default test suites on a cmake -DWITH_UBSAN=ON build no longer fail due to passing null pointers as parameters that are declared to never be null, but plenty of other runtime errors remain.
* | | | | Merge 10.5 into 10.6Marko Mäkelä2020-11-021-1/+0
|\ \ \ \ \ | |/ / / /
| * | | | Merge 10.4 into 10.5Marko Mäkelä2020-10-301-1/+0
| |\ \ \ \ | | |/ / /
| | * | | Merge 10.3 into 10.4Marko Mäkelä2020-10-291-1/+0
| | |\ \ \ | | | |/ /
| | | * | MDEV-21201 No records produced in information_schema query, depending on ↵Sergei Golubchik2020-10-231-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | projection Reimplement MDEV-14275 Improving memory utilization for information schema Postpone temp table instantiation until after setup_fields(). Replace all unused (not marked in read_set) columns in an I_S table with CHAR(0). This can drastically reduce the footprint of a MEMORY table (a TABLE_CATALOG alone is 1538 bytes per row). This does not change the engine. If the table was decided to be Aria (because of, say, blobs) then after optimization it'll stay Aria even if all blobs were removed. Note 1: when transforming table structure, share->blob_fields is preserved, otherwise Aria might switch from DYNAMIC to STATIC row format and expect a special field for a deleted mark, which create_tmp_tabe didn't provide. Note 2: optimizer was doing handler::info() (to know the number of rows) before the temp table is populated. That didn't make much sense. Now it's done before the table is even instantiated. Preserve the old behavior and report 0 rows. This reverts e2664ee8362 and a8458a2345e
* | | | | Merge 10.5 into 10.6Marko Mäkelä2020-08-121-3/+10
|\ \ \ \ \ | |/ / / /
| * | | | Merge 10.4 into 10.5Marko Mäkelä2020-08-101-3/+10
| |\ \ \ \ | | |/ / /
| | * | | Merge 10.3 into 10.4Marko Mäkelä2020-08-101-3/+10
| | |\ \ \ | | | |/ /
| | | * | Merge 10.2 into 10.3Marko Mäkelä2020-08-101-3/+10
| | | |\ \ | | | | |/
| | | | * Merge 10.1 into 10.2Marko Mäkelä2020-08-101-3/+10
| | | | |\
| | | | | * Better comment about TABLE::maybe_nullSergei Petrunia2020-08-061-3/+10
| | | | | |
* | | | | | Merge 10.5 into 10.6Marko Mäkelä2020-08-041-0/+2
|\ \ \ \ \ \ | |/ / / / /
| * | | | | Merge 10.4 into 10.5Marko Mäkelä2020-08-011-0/+1
| |\ \ \ \ \ | | |/ / / /
| | * | | | Merge 10.3 into 10.4Marko Mäkelä2020-07-311-0/+1
| | |\ \ \ \ | | | |/ / /
| | | * | | MDEV-21201 No records produced in information_schema query, depending on ↵Oleksandr Byelkin2020-07-311-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | projection In case of NATURAL JOIN / USING mark all field (one table can not be opened in any case so optimisation does not worth it). IMHO table should be checked for used fields and filled after prepare, when we will fave whole info about used fields but it is too big change for a bugfix. Which will be made later by Serg patch
| * | | | | Merge 10.4 into 10.5Marko Mäkelä2020-08-011-0/+1
| |\ \ \ \ \ | | |/ / / /
| | * | | | Merge 10.3 into 10.4Marko Mäkelä2020-07-311-0/+1
| | |\ \ \ \ | | | |/ / /
| | | * | | Merge 10.2 into 10.3Marko Mäkelä2020-07-311-1/+2
| | | |\ \ \ | | | | |/ /
| | | | * | MDEV-16039 Crash when selecting virtual columns generated using functions ↵Nikita Malyavin2020-07-211-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | with DAYNAME() * Allocate items on thd->mem_root while refixing vcol exprs * Make vcol tree changes register and roll them back after the statement is executed. Explanation: Due to collation implementation specifics an Item tree could change while fixing. The tricky thing here is to make it on a proper arena. It's usually not a problem when a field is deterministic, however, makes a pain vice-versa, during allocation allocating. A non-deterministic field should be refixed on each statement, since it depends on the environment state. Changing the tree will be temporary and therefore it should be reverted after the statement execution.
* | | | | | MDEV-13694: Wrong result upon GROUP BY with orderby_uses_equalities=onVarun Gupta2020-07-081-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For the case when the SJM scan table is the first table in the join order, then if we want to do the sorting on the SJM scan table, then we need to make sure that we unpack the values to base table fields in two cases: 1) Reading the SJM table and writing the sort-keys inside the sort-buffer 2) Reading the sorted data from the sort file
* | | | | | merge 10.5Vladislav Vaintroub2020-07-041-1/+2
|\ \ \ \ \ \ | |/ / / / /
| * | | | | MDEV-22535 fixup: Define a single-caller function inlineMarko Mäkelä2020-07-041-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | Let us avoid any overhead in release builds, for an empty function.
* | | | | | Merge branch '10.5' into 10.6Vladislav Vaintroub2020-07-041-31/+123
|\ \ \ \ \ \ | |/ / / / /
| * | | | | MDEV-22535 TABLE::initialize_quick_structures() takes 0.5% in oltp_read_onlyMonty2020-07-021-22/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixed by: - Make all quick_* variable allocated according to real number keys instead of MAX_KEY - Store all the quick* items in separated allocated structure (OPT_RANGE) - Ensure we don't access any quick* variable without first checking opt_range_keys.is_set(). Thanks to this, we don't need any pre-initialization of quick* variables anymore. Some renames was done to use the new structure: table->quick_keys -> table->opt_range_keys table->quick_rows[X] -> table->opt_range[X].rows table->quick_key_parts[X] -> table->opt_range[X].key_parts table->quick_costs[X] -> table->opt_range[X].cost table->quick_index_only_costs[X] -> table->opt_range[X].index_only_cost table->quick_n_ranges[X] -> table->opt_range[X].ranges table->quick_condition_rows -> table->opt_range_condition_rows This patch should both decrease memory needed for TABLE objects (3528 -> 984 + keyinfo) and increase performance, thanks to less initializations per query, and more localized memory, thanks to the opt_range structure.
| * | | | | Merge 10.4 into 10.5Marko Mäkelä2020-07-021-2/+4
| |\ \ \ \ \ | | |/ / / /
| | * | | | Merge 10.3 into 10.4Marko Mäkelä2020-07-021-2/+4
| | |\ \ \ \ | | | |/ / /
| | | * | | MDEV-22866: Crash in join optimizer with constant outer join nestSergei Petrunia2020-06-231-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Starting from 10.3, the optimizer is able to detect that entire outer join nests are constants (because of "Impossible ON") and remove them (see mark_join_nest_as_const) However, this was not properly accounted for in NESTED_JOIN structure and the way check_interleaving_with_nj() uses its n_tables member to check if the join prefix order is allowed. (The result was that the optimizer could conclude that no join prefix is allowed and fail an assertion)
| * | | | | remove dead codeSergei Golubchik2020-06-091-8/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | reduce the amount of engine-specific code in the server, particularly as it does not serve any purpose now. may be needed for VP engine, to be reconsidered in MDEV-7795
| * | | | | MDEV-6268 SPIDER table with no COMMENT clause causes queries to wait foreverKentoku SHIBA2020-06-051-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add looping check Conflicts: sql/table.h
| * | | | | Merge 10.4 into 10.5Marko Mäkelä2020-06-031-6/+86
| |\ \ \ \ \ | | |/ / / /
| | * | | | Merge 10.3 into 10.4Marko Mäkelä2020-06-031-7/+87
| | |\ \ \ \ | | | |/ / /
| | | * | | Merge 10.2 into 10.3Marko Mäkelä2020-06-021-6/+85
| | | |\ \ \ | | | | |/ /
| | | | * | Merge 10.1 into 10.2Marko Mäkelä2020-06-011-6/+85
| | | | |\ \ | | | | | |/
| | | | | * Thread safe histograms loadingSergey Vojtovich2020-05-291-2/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously multiple threads were allowed to load histograms concurrently. There were no known problems caused by this. But given amount of data races in this code, it'd happen sooner or later. To avoid scalability bottleneck, histograms loading is protected by per-TABLE_SHARE atomic variable. Whenever histograms were loaded by preceding statement (hot-path), a scalable load-acquire check is performed. Whenever histograms have to be loaded anew, mutual exclusion for loaders is established by atomic variable. If histograms are being loaded concurrently, statement waits until load is completed. - Table_statistics::total_hist_size moved to TABLE_STATISTICS_CB: only meaningful within TABLE_SHARE (not used for collected stats). - TABLE_STATISTICS_CB::histograms_can_be_read and TABLE_STATISTICS_CB::histograms_are_read are replaced with a tri state atomic variable. - Simplified away alloc_histograms_for_table_share(). Note: there's still likely a data race if a thread attempts accessing histograms data after it failed to load it (because of concurrent load). It was there previously and goes out of the scope of this effort. One way of fixing it could be reviving TABLE::histograms_are_read and adding appropriate checks whenever it is needed. Part of MDEV-19061 - table_share used for reading statistical tables is not protected
| | | | | * Thread safe statistics loadingSergey Vojtovich2020-05-291-4/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously multiple threads were allowed to load statistics concurrently. There were no known problems caused by this. But given amount of data races in this code, it'd happen sooner or later. To avoid scalability bottleneck, statistics loading is protected by per-TABLE_SHARE atomic variable. Whenever statistics were loaded by preceding statement (hot-path), a scalable load-acquire check is performed. Whenever statistics have to be loaded anew, mutual exclusion for loaders is established by atomic variable. If statistics are being loaded concurrently, statement waits until load is completed. TABLE_STATISTICS_CB::stats_can_be_read and TABLE_STATISTICS_CB::stats_is_read are replaced with a tri state atomic variable. Part of MDEV-19061 - table_share used for reading statistical tables is not protected
| * | | | | Merge 10.4 into 10.5Marko Mäkelä2020-05-311-1/+11
| |\ \ \ \ \ | | |/ / / /