summaryrefslogtreecommitdiff
path: root/storage/tokudb
Commit message (Collapse)AuthorAgeFilesLines
* remove tokudb tests (fix bad merge)Sergei Golubchik2021-08-282-24/+0
|
* Merge branch '10.5' into 10.6Oleksandr Byelkin2021-08-022-0/+24
|\
| * Merge branch '10.4' into 10.5Oleksandr Byelkin2021-07-313-2/+26
| |\
| | * Merge branch '10.3' into 10.4Oleksandr Byelkin2021-07-313-2/+26
| | |\
| | | * Merge 10.2 into 10.3Marko Mäkelä2021-07-273-2/+26
| | | |\
| | | | * MDEV-23786: Assertion `!is_set() || (m_status == DA_OK_BULK && is_bulk_op())'Rucha Deodhar2021-07-263-2/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | failed for TokuDB engine CREATE TABLE Analysis: Assertion failure happens because the database doesn't exist to create the table but ha_tokudb::create() still returns false. So error is not reported. Fix: Store the error state and report the error.
| * | | | Fix various spelling errors still found in codeOtto Kekäläinen2021-03-221-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reseting -> Resetting Unknow -> Unknown capabilites -> capabilities choosen -> chosen direcory -> directory informations -> information openned -> opened refered -> referred to access -> one to access missmatch -> mismatch succesfully -> successfully dont -> don't
| * | | | Merge branch '10.4' into 10.5Sergei Golubchik2021-02-231-3/+2
| |\ \ \ \ | | |/ / /
| | * | | Merge branch '10.3' into 10.4Sergei Golubchik2021-02-231-3/+2
| | |\ \ \ | | | |/ /
| | | * | Merge branch '10.2' into 10.3Sergei Golubchik2021-02-221-3/+2
| | | |\ \ | | | | |/
| | | | * MDEV-24790 CAST('0e1111111111' AS DECIMAL(38,0)) returns a wrong resultAlexander Barkov2021-02-081-3/+2
| | | | |
| | | | * MDEV-17556 Assertion `bitmap_is_set_all(&table->s->all_set)' failedNikita Malyavin2021-01-081-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 branch 'bb-10.4-release' into bb-10.5-releaseSergei Golubchik2021-02-151-8/+8
| |\ \ \ \ | | |/ / /
| | * | | Merge branch 'bb-10.3-release' into bb-10.4-releaseSergei Golubchik2021-02-121-8/+8
| | |\ \ \ | | | |/ / | | | | | | | | | | | | | | | 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-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.3 into 10.4Marko Mäkelä2020-11-032-2/+9
| | |\ \ \ | | | |/ /
| * | | | Merge branch '10.4' into 10.5Oleksandr Byelkin2020-11-012-2/+9
| |\ \ \ \
| | * \ \ \ Merge branch '10.3' into 10.4Oleksandr Byelkin2020-10-312-2/+9
| | |\ \ \ \ | | | |/ / / | | |/| / / | | | |/ /
| | | * | Merge branch '10.2' into 10.3Oleksandr Byelkin2020-10-302-2/+9
| | | |\ \ | | | | |/
| | | | * Merge branch '10.1' into 10.2Oleksandr Byelkin2020-10-292-2/+9
| | | | |\
| | | | | * MDEV-23702 calculating(auto rounding) issueSergei Golubchik2020-10-292-4/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Implement a different fix for "MDEV-19232: Floating point precision / value comparison problem" Instead of truncating decimal values after every division, truncate them for comparison purposes. This reverts commit 62d73df6b270 but keeps the test.
| * | | | | Merge 10.4 into 10.5Marko Mäkelä2020-10-301-0/+3
| |\ \ \ \ \ | | |/ / / /
| | * | | | MDEV-21954 mysqld got signal 11 Fatal signal 6 while backtracing on parallel ↵Sergei Golubchik2020-10-231-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | show global status protect global toku_global_status_rows with a mutex
| * | | | | MDEV-22100 TokuDB compilation errorSergei Golubchik2020-10-243-16/+4
| | | | | | | | | | | | | | | | | | | | | | | | fix TokuDB to compile with the perfschema
| * | | | | Merge 10.4 into 10.5Marko Mäkelä2020-08-211-1/+1
| |\ \ \ \ \ | | |/ / / /
| | * | | | Merge 10.3 into 10.4Marko Mäkelä2020-08-211-1/+1
| | |\ \ \ \ | | | |/ / /
| | | * | | Merge 10.2 into 10.3Marko Mäkelä2020-08-211-1/+1
| | | |\ \ \ | | | | |/ /
| * | | | | Merge branch '10.4' into 10.5mariadb-10.5.5Sergei Golubchik2020-08-0741-99/+94
| |\ \ \ \ \ | | |/ / / /
| | * | | | Merge branch '10.3' into 10.4mariadb-10.4.14Sergei Golubchik2020-08-0641-99/+94
| | |\ \ \ \ | | | |/ / /
| | | * | | Merge branch '10.2' into 10.3mariadb-10.3.24Sergei Golubchik2020-08-0641-99/+94
| | | |\ \ \ | | | | |/ /
| | | | * | Merge branch '10.1' into 10.2mariadb-10.2.33Sergei Golubchik2020-08-0641-99/+94
| | | | |\ \ | | | | | |/
| | | | | * Merge branch 'merge/merge-tokudb-5.6' into 10.1Sergei Golubchik2020-08-0542-100/+95
| | | | | |\
| | | | | | * 5.6.49-89.0Sergei Golubchik2020-08-0447-148/+125
| | | | | | |
| * | | | | | Merge branch '10.4' into 10.5Oleksandr Byelkin2020-08-042-9/+2
| |\ \ \ \ \ \ | | |/ / / / /
| | * | | | | Merge branch '10.3' into 10.4Oleksandr Byelkin2020-08-032-9/+2
| | |\ \ \ \ \ | | | |/ / / /
| | | * | | | Merge branch '10.2' into 10.3Oleksandr Byelkin2020-08-032-9/+2
| | | |\ \ \ \ | | | | |/ / /
| | | | * | | Merge branch '10.1' into 10.2Oleksandr Byelkin2020-08-022-9/+2
| | | | |\ \ \ | | | | | |/ /
| | | | | * | MDEV-19232: Floating point precision / value comparison problemVarun Gupta2020-07-222-9/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The issue occurs when the subquery_cache is enabled. When there is a cache miss the division was leading to a value with scale 9. In the case of cache hit the value returned was of scale 9 and due to the different values for the scales the where condition evaluated to FALSE, hence the output was incomplete. To fix this problem we need to round up the decimal to the limit mentioned in Item::decimals. This would make sure the values are compared with the same scale.
| | | | * | | get rid of cmake warningSergei Golubchik2020-05-271-1/+1
| | | | | | |
| * | | | | | Merge remote-tracking branch 'origin/10.4' into 10.5Monty2020-07-031-0/+5
| |\ \ \ \ \ \ | | |/ / / / /
| | * | | | | Merge remote-tracking branch 'origin/10.3' into 10.4Monty2020-07-031-0/+5
| | |\ \ \ \ \ | | | |/ / / /
| | | * | | | Fixed bugs found by valgrindMonty2020-07-021-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Some of the bug fixes are backports from 10.5! - The fix in innobase/fil/fil0fil.cc is just a backport to get less error messages in mysqld.1.err when running with valgrind. - Renamed HAVE_valgrind_or_MSAN to HAVE_valgrind
| * | | | | | Merge 10.4 into 10.5Marko Mäkelä2020-05-181-0/+8
| |\ \ \ \ \ \ | | |/ / / / /
| | * | | | | Merge 10.3 into 10.4Marko Mäkelä2020-05-161-0/+8
| | |\ \ \ \ \ | | | |/ / / / | | | | | | | | | | | | | | | | | | | | | We will expose some more std::atomic internals in Atomic_counter, so that dict_index_t::lock will support the default assignment operator.
| | | * | | | Merge 10.2 into 10.3Marko Mäkelä2020-05-151-0/+8
| | | |\ \ \ \ | | | | |/ / /
| | | | * | | MDEV-19622: Fix a TokuDB resultMarko Mäkelä2020-05-141-0/+8
| | | | | | |
* | | | | | | MDEV-19780 Remove the TokuDB storage engineMarko Mäkelä2020-05-143231-2491632/+0
|/ / / / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The TokuDB storage engine has been deprecated by upstream Percona Server 8.0 in favor of MyRocks and will not be available in subsequent major upstream releases. Let us remove it from MariaDB Server as well. MyRocks is actively maintained, and it can be used instead.
* | | | | | Merge branch '10.4' into 10.5Sergei Golubchik2020-05-092-8/+8
|\ \ \ \ \ \ | |/ / / / /
| * | | | | MDEV-21794: Optimizer flag rowid_filter leads to long querySergei Petrunia2020-05-072-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Rowid Filter check is just like Index Condition Pushdown check: before we check the filter, we must check if we have walked out of the range we are scanning. (If we did, we should return, and not continue the scan). Consequences of this: - Rowid filtering doesn't work for keys that have partially-covered blob columns (just like Index Condition Pushdown) - The rowid filter function has three return values: CHECK_POS (passed) CHECK_NEG (filtered out), CHECK_OUT_OF_RANGE. All of the above is implemented in this patch
* | | | | | Merge 10.4 into 10.5Marko Mäkelä2020-05-052-4/+4
|\ \ \ \ \ \ | |/ / / / /