summaryrefslogtreecommitdiff
path: root/storage/spider
Commit message (Collapse)AuthorAgeFilesLines
* Merge branch '10.3' into 10.4Oleksandr Byelkin2022-01-303-6/+28
|\
| * MDEV-26768 Spider table crashes the server after the mysql_list_fields() ↵bb-10.3-hf-2Alexey Botchkov2022-01-203-6/+28
| | | | | | | | | | | | client's call and produces weird result for SHOW FIELDS. Suppress errors in ha_spider::info() called from mysqld_show_fields()
| * MDEV-19866 follow-upbb-10.3-mdev-26333Nayuta Yanagisawa2021-10-181-4/+4
| | | | | | | | | | | | Cherry-picking the fix for MDEV-19866 changes the behavior of the Spider slightly. So, I modified a existing test to match the new behavior.
| * MDEV-19866 With a Spider table, a SELECT with WHERE involving primary key ↵Kentoku SHIBA2021-10-186-30/+310
| | | | | | | | | | breaks following SELECTs (#1356) Change checking scanning partitions from part_spec to part_info->read_partitions
* | MDEV-26583 SIGSEGV's in spider_get_select_limit_from_select_lex when DELAYED ↵Nayuta Yanagisawa2022-01-193-0/+81
| | | | | | | | | | | | INSERT is used Spider dereferences a freed select_lex and then results in SIGSEGV.
* | Revert "MDEV-26345 SELECT MIN on Spider table returns more rows than expected"bb-10.4-mdev-26345Nayuta Yanagisawa2022-01-144-97/+1
| | | | | | | | This reverts commit b9730226dce5bf34b87aa28963f1df68a695a93c.
* | MDEV-26345 SELECT MIN on Spider table returns more rows than expectedNayuta Yanagisawa2022-01-114-1/+97
| | | | | | | | | | | | | | | | | | The Spider storage engine ignored the implicit grouping when aggregation was converted to constant by the query optimizer. As a result, the Spider SE returned rows more than expected. To fix the problem, we notify the Spider SE of the existence of the implicit grouping via Query::distinct.
* | MDEV-27184 Assertion `(old_top == initial_top (av) && old_size == 0) || ↵Nayuta Yanagisawa2021-12-274-1/+55
| | | | | | | | | | | | | | ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)' failed, Assertion `str.alloced_length() >= str.length() + data_len' failed Spider crashes on a query that inserts some rows including float. This is because Spider allocates a string of insufficient length.
* | Merge 10.3 into 10.4Marko Mäkelä2021-09-225-1/+414
|\ \ | |/
| * MDEV-26545 Spider does not correctly handle UDF and stored function in where ↵Daniel Ye2021-09-225-1/+414
| | | | | | | | | | | | | | conds - Handle stored function conditions correctly, with the same logic as with UDFs. - When running queries on Spider SE, by default, we do not push down WHERE conditions containing usage of UDFs/stored functions to remote data nodes, unless the user demands (by setting spider_use_pushdown_udf). - Disable direct update/delete when a udf condition is skipped.
* | Merge 10.3 into 10.4Marko Mäkelä2021-08-185-0/+167
|\ \ | |/
| * MDEV-24523 Execution of JSON_REPLACE failed on SpiderYongxin Xu2021-08-055-0/+167
| | | | | | | | | | | | | | | | | | | | JSON_REPLACE() function executed with an error on Spider SE. This patch fixes the problem, and it also fixes the MDEV-24541. The problem is that Item_func_json_insert::func_name() returns the wrong function name "json_update". The Spider SE reconstructs a query based on the return value in some cases. Thus, if the return value is wrong, the Spider SE may generate a wrong query.
* | Merge branch '10.3' into 10.4Oleksandr Byelkin2021-07-3119-63/+847
|\ \ | |/
| * MDEV-24020: Trim with remove_str Fails on SpiderYongxin Xu2021-07-297-9/+366
| | | | | | | | This patch fixes the bug that TRIM(BOTH ... FROM $str), TRIM(LEADING ... FROM $str), and TRIM(TRAILING ... FROM $str) failed with errors when executing on Spider.
| * MDEV-24517 follow-up: Fix for test with --ps-protocolNayuta Yanagisawa2021-07-251-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | Tests for the Spider storage engine often use the following idiom: --let $command=CREATE TABLE t1 (...);CREATE TABLE t2 (...); ... --eval $command However, the idiom seems to work in the normal protocol, but fails in the prepared statement (ps) protocol. As testing CREATE TABLE statements in the ps protocol, we wrap the idiom by --disable_ps_protocol and --enable_ps_protocol.
| * MDEV-24517: JSON_EXTRACT as conditions triggers syntax error on Spider (#1839)Yongxin Xu2021-07-236-0/+230
| | | | | | | | | | | | | | | | | | The `item_func::JSON_EXTRACT_FUNC` was not handled correctly in the previous versions on the Spider storage engine, which makes queries like `SELECT * FROM t1 WHERE json_extract(jdoc, '$.Age')=20` failed with syntax error. This patch writes specific code to handle JSON_EXTRACT in the Spider Storage Engine and fix that bug.
| * Merge branch '10.2' into 10.3Sergei Golubchik2021-07-214-9/+107
| |\
| | * MDEV-25985 Spider handle ">=" as ">" in some casesNayuta Yanagisawa2021-07-144-9/+107
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The function spider_db_append_key_where_internal() converts HA_READ_AFTER_KEY to '>'. The conversion seems to be correct for single-column indexes because HA_READ_AFTER_KEY means "read the key after the provided value." However, how about multi-column indexes? Assume that there is a multi-column index on c1 and c2 and we search with the condition 'c1 >= 100 AND c2 > 200'. The key_range.flag corresponds to the search condition could be HA_READ_AFTER_KEY. In such a case, we could not simply convert HA_READ_AFTER_KEY to '>'. The correct conversion is to convert HA_READ_AFTER_KEY to '>' only for the last column in key_part_map and to convert HA_READ_AFTER_KEY to '>=' for the other column. The similar discussion also applies to the conversion from key_range.flag to a sign of inequality.
| | * MDEV-17556 Assertion `bitmap_is_set_all(&table->s->all_set)' failedNikita Malyavin2021-01-083-39/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-7098 spider/bg.spider_fixes failed in buildbot with safe_mutex: Trying ↵Kentoku SHIBA2020-09-077-539/+1534
| | | | | | | | | | | | to unlock mutex conn->mta_conn_mutex that wasn't locked at storage/spider/spd_db_conn.cc, line 671
| * | MDEV-24760 SELECT..CASE statement syntax error at Spider Engine tableNayuta Yanagisawa2021-07-194-79/+176
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The root cause of the bug is in `spider_db_mbase_util::open_item_func()`. The function handles an instance of the `Item_func` class based on its `Item_func::Functype`. The `Functype` of `CASE WHEN ... THEN` is `CASE_SEARCHED_FUNC`. However, the Spider SE doesn't recognize this `Functype` because `CASE_SEARCHED_FUNC` is newly added by 4de0d92. This results in the wrong handling of `CASE WHEN ... THEN`. The above also applies to `CASE_SIMPLE_FUNC`.
* | | disable spider/bugfix.wait_timeoutSergei Golubchik2021-07-261-0/+1
| | |
* | | fix spider/bugfix.delete_with_float_column_mysql --psSergei Golubchik2021-07-251-0/+2
| | | | | | | | | | | | as always, multi-commands don't work in --ps
* | | MDEV-26013 distinct not work properly in some cases for spider tablesNayuta Yanagisawa2021-07-223-0/+96
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The bug is caused by the following reasons: * spider_group_by_handler::init_scan() generates a query for a data node. * The function adds DISTINCT if and only if spider_group_by_handler::query::distinct is TRUE. * spider_group_by_handler::query::distinct is set to the value of JOIN::select_distinct in JOIN::make_aggr_tables_info(). * In the test case, DISTINCT is not added because JOIN::select_distinct is FALSE at the call of JOIN::make_aggr_tables_info(). Why JOIN::select_distinct is set to FALSE? That is because the function JOIN::optimize_stage2() convert DISTINCT into GROUP BY and then optimizes away GROUP BY.
* | | MDEV-26139 Spider crashes with segmentation fault (signal 11) on CREATE ↵Nayuta Yanagisawa2021-07-143-2/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TABLE when COMMENT does not contain embedded double quotes The root cause of the bug MDEV-26139 is the lack of NULL checking on the variable `dq`. Comments on if (dq && (!sq || sq > dq)) {...} else {...}: * The if block corresponds to the case where parameters are quoted by double quotes. In that case, a single quote doesn't appear at all or only appears in the middle of double quotes. * The else block corresponds to the case where parameters are quoted by single quotes. In that case, a double quote doesn't appear at all or only appears in the middle of single quotes. * If the program reaches the if-else statement, `sq || dq` holds. Thus, the negation of `dq && (!sq || sq > dq)` is equivalent to `sq && (!dq || sq <= dq)`.
* | | Merge 10.3 into 10.4Marko Mäkelä2021-06-218-4/+11
|\ \ \ | |/ /
| * | fix spider tests for --psSergei Golubchik2021-06-194-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | spider tests use --let $var= many;sql;statements --eval $var and this doesn't work in ps
| * | spider tests aren't bigSergei Golubchik2021-06-194-4/+0
| | | | | | | | | | | | | | | | | | and *never* disable tests in suite.pm based on $::opt_big_test, this will make the test skipped both as too big (for ./mtr) and as too small (for ./mtr --big --big).
* | | fix spider tests for --ps in 10.4Sergei Golubchik2021-06-192-0/+8
| | | | | | | | | | | | see also 068246c006b
* | | spider tests aren't big in 10.4Sergei Golubchik2021-06-193-3/+0
| | | | | | | | | | | | see also a5f6eca50db
* | | MDEV-22265 Connect string character limit too small for full 64 character ↵Kentoku SHIBA2021-04-295-0/+67
| | | | | | | | | | | | | | | | | | InnoDB table-name limit when using ad-hoc Spider server definitions. Fix length for getting default table name.
* | | MDEV-22265 Connect string character limit too small for full 64 character ↵Alexey Botchkov2021-04-273-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | InnoDB table-name limit when using ad-hoc Spider server definitions. The name of the table sent as an argument to the handler::init() has the database name in front of it. So we should use table_share->table_name.length.
* | | Merge branch 'bb-10.3-release' into bb-10.4-releaseSergei Golubchik2021-02-123-45/+44
|\ \ \ | |/ / | | | | | | | | | 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-273-45/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-20502 Queries against spider tables return wrong values for columns ↵Kentoku SHIBA2021-01-122-0/+31
| | | | | | | | | | | | | | | | | | following constant declarations. Add test cases.
| * | MDEV-20502 Queries against spider tables return wrong values for columns ↵Kentoku SHIBA2021-01-1210-4/+216
| | | | | | | | | | | | | | | | | | following constant declarations. When executing a query like "select id, 0 as const, val from ...", there are 3 columns(items) in Query->select at handlerton->create_group_by(). After that, MariaDB makes a temporary table with 2 columns. The skipped items are const item, so fixing Spider to skip const items for items at Query->select.
| * | MDEV-20100 MariaDB 13.3.9 Crash "[ERROR] mysqld got signal 11 ;"Kentoku SHIBA2020-10-205-0/+264
| | | | | | | | | | | | Some functions on ha_partition call functions on all partitions, but handler->reset() is only called that pruned by m_partitions_to_reset. So Spider didn't clear pointer on unpruned partitions, if the unpruned partitions are used by next query, Spider reference the pointer that is already freed.
| * | MDEV-7098 spider/bg.spider_fixes failed in buildbot with safe_mutex: Trying ↵Kentoku SHIBA2020-09-078-543/+1622
| | | | | | | | | | | | to unlock mutex conn->mta_conn_mutex that wasn't locked at storage/spider/spd_db_conn.cc, line 671
| * | MDEV-18993 The keep-alive connection (set spider_conn_recycle_mode = 1) in ↵Kentoku SHIBA2020-06-272-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | spider would cause cash in MariaDB (#1269) Fix the following valgrind error. ==94390== Thread 29: ==94390== Invalid read of size 8 ==94390== at 0x78389D: thd_increment_bytes_sent (sql_class.cc:4265) ==94390== by 0xC8EC46: net_real_write (net_serv.cc:730) ==94390== by 0xC8E0C8: net_flush (net_serv.cc:383) ==94390== by 0xC8E4D0: net_write_command (net_serv.cc:521) ==94390== by 0xADCE61: cli_advanced_command (client.c:468) ==94390== by 0xAE3CAF: mysql_close_slow_part (client.c:3671) ==94390== by 0xAE3D28: mysql_close (client.c:3683) ==94390== by 0x149E69A8: spider_db_mbase::disconnect() (spd_db_mysql.cc:2217) ==94390== by 0x1491EA26: spider_db_disconnect(st_spider_conn*) (spd_db_conn.cc:297) ==94390== by 0x14948EBE: spider_free_conn_alloc(st_spider_conn*) (spd_conn.cc:196) ==94390== by 0x1494B26A: spider_free_conn(st_spider_conn*) (spd_conn.cc:1251) ==94390== by 0x1494941F: spider_free_conn_from_trx(st_spider_transaction*, st_spider_conn*, bool, bool, int*) (spd_conn.cc:315) ==94390== Address 0x1f0e0990 is 4,832 bytes inside a block of size 25,728 free'd ==94390== at 0x4C2ACBD: free (vg_replace_malloc.c:530) ==94390== by 0x13F5545: my_free (my_malloc.c:222) ==94390== by 0x6C75B7: ilink::operator delete(void*, unsigned long) (sql_list.h:618) ==94390== by 0x77B9F6: THD::~THD() (sql_class.cc:1724) ==94390== by 0x1494FCE0: spider_bg_conn_action(void*) (spd_conn.cc:2580) ==94390== by 0x4E3DDD4: start_thread (in /usr/lib64/libpthread-2.17.so) ==94390== by 0x5FBFEAC: clone (in /usr/lib64/libc-2.17.so) ==94390== Block was alloc'd at ==94390== at 0x4C29BC3: malloc (vg_replace_malloc.c:299) ==94390== by 0x13F4DFA: my_malloc (my_malloc.c:101) ==94390== by 0x1491CF06: ilink::operator new(unsigned long) (sql_list.h:614) ==94390== by 0x1494F7FD: spider_bg_conn_action(void*) (spd_conn.cc:2501) ==94390== by 0x4E3DDD4: start_thread (in /usr/lib64/libpthread-2.17.so) ==94390== by 0x5FBFEAC: clone (in /usr/lib64/libc-2.17.so) ==94390== Invalid write of size 8 ==94390== at 0x7838AF: thd_increment_bytes_sent (sql_class.cc:4265) ==94390== by 0xC8EC46: net_real_write (net_serv.cc:730) ==94390== by 0xC8E0C8: net_flush (net_serv.cc:383) ==94390== by 0xC8E4D0: net_write_command (net_serv.cc:521) ==94390== by 0xADCE61: cli_advanced_command (client.c:468) ==94390== by 0xAE3CAF: mysql_close_slow_part (client.c:3671) ==94390== by 0xAE3D28: mysql_close (client.c:3683) ==94390== by 0x149E69A8: spider_db_mbase::disconnect() (spd_db_mysql.cc:2217) ==94390== by 0x1491EA26: spider_db_disconnect(st_spider_conn*) (spd_db_conn.cc:297) ==94390== by 0x14948EBE: spider_free_conn_alloc(st_spider_conn*) (spd_conn.cc:196) ==94390== by 0x1494B26A: spider_free_conn(st_spider_conn*) (spd_conn.cc:1251) ==94390== by 0x1494941F: spider_free_conn_from_trx(st_spider_transaction*, st_spider_conn*, bool, bool, int*) (spd_conn.cc:315) ==94390== Address 0x1f0e0990 is 4,832 bytes inside a block of size 25,728 free'd ==94390== at 0x4C2ACBD: free (vg_replace_malloc.c:530) ==94390== by 0x13F5545: my_free (my_malloc.c:222) ==94390== by 0x6C75B7: ilink::operator delete(void*, unsigned long) (sql_list.h:618) ==94390== by 0x77B9F6: THD::~THD() (sql_class.cc:1724) ==94390== by 0x1494FCE0: spider_bg_conn_action(void*) (spd_conn.cc:2580) ==94390== by 0x4E3DDD4: start_thread (in /usr/lib64/libpthread-2.17.so) ==94390== by 0x5FBFEAC: clone (in /usr/lib64/libc-2.17.so) ==94390== Block was alloc'd at ==94390== at 0x4C29BC3: malloc (vg_replace_malloc.c:299) ==94390== by 0x13F4DFA: my_malloc (my_malloc.c:101) ==94390== by 0x1491CF06: ilink::operator new(unsigned long) (sql_list.h:614) ==94390== by 0x1494F7FD: spider_bg_conn_action(void*) (spd_conn.cc:2501) ==94390== by 0x4E3DDD4: start_thread (in /usr/lib64/libpthread-2.17.so) ==94390== by 0x5FBFEAC: clone (in /usr/lib64/libc-2.17.so)
| * | MDEV-21884 MariaDB with Spider crashes on a querybb-10.3-MDEV-21884Kentoku SHIBA2020-04-176-0/+293
| | |
* | | MDEV-20100 MariaDB 13.3.9 Crash "[ERROR] mysqld got signal 11 ;"Kentoku SHIBA2020-10-225-0/+264
| | | | | | | | | | | | Some functions on ha_partition call functions on all partitions, but handler->reset() is only called that pruned by m_partitions_to_reset. So Spider didn't clear pointer on unpruned partitions, if the unpruned partitions are used by next query, Spider reference the pointer that is already freed.
* | | MDEV-7098 spider/bg.spider_fixes failed in buildbot with safe_mutex: Trying ↵bb-10.4-midenok-MDEV-18706Kentoku SHIBA2020-09-078-545/+1658
| | | | | | | | | | | | to unlock mutex conn->mta_conn_mutex that wasn't locked at storage/spider/spd_db_conn.cc, line 671
* | | MDEV-22246 Result rows duplicated by spider engineKentoku SHIBA2020-08-249-0/+335
| | | | | | | | | | | | | | | fix the following type mrr scan (select 0,`id`,`node` from `auto_test_remote`.`tbl_a` where (`id` <> 0) order by `id`)union all(select 1,`id`,`node` from `auto_test_remote`.`tbl_a` where (`id` <> 0) order by `id`) order by `id`
* | | MDEV-20827 Wrong param parsing in spider_direct_sql() when param contain commaKentoku SHIBA2020-08-179-33/+213
| | |
* | | MDEV-19794 Spider crash with XAKentoku SHIBA2020-08-146-4/+191
| | |
* | | MDEV-20502 Queries against spider tables return wrong values for columns ↵Kentoku SHIBA2020-05-052-0/+31
| | | | | | | | | | | | | | | | | | following constant declarations. Add test cases.
* | | MDEV-21884 MariaDB with Spider crashes on a queryKentoku SHIBA2020-04-231-5/+2
| | | | | | | | | | | | Fix a test result.
* | | MDEV-20502 Queries against spider tables return wrong values for columns ↵Kentoku SHIBA2020-04-1710-4/+216
| | | | | | | | | | | | | | | | | | following constant declarations. When executing a query like "select id, 0 as const, val from ...", there are 3 columns(items) in Query->select at handlerton->create_group_by(). After that, MariaDB makes a temporary table with 2 columns. The skipped items are const item, so fixing Spider to skip const items for items at Query->select.
* | | MDEV-21884 MariaDB with Spider crashes on a queryKentoku SHIBA2020-04-176-0/+293
| | |
* | | Merge 10.3 into 10.4Marko Mäkelä2020-03-301-1/+1
|\ \ \ | |/ /
View Lorry Controller Status