summaryrefslogtreecommitdiff
path: root/storage/spider
Commit message (Collapse)AuthorAgeFilesLines
* MDEV-29644 a potential bug of null pointer dereference in ↵bb-10.3-mdev-29644Nayuta Yanagisawa2023-02-035-56/+136
| | | | | | | | | | | | | | spider_db_mbase::print_warnings() The function spider_db_mbase::print_warnings() can potentially result in a null pointer dereference. Remove the null pointer dereference by cleaning up the function. Some small changes to the original commit 422fb63a9bbee35c50b6c7be19d199afe0bc98fa. Co-Authored-By: Yuchen Pei <yuchen.pei@mariadb.com>
* MDEV-29988: (spider fix) Major performance regression with 10.6.11Oleksandr Byelkin2023-01-021-0/+6
| | | | Make Item_direct_ref_to_item transparent for Spider
* MDEV-29562 Spider table charset error should happen correctly.Yuchen Pei2022-12-204-0/+114
| | | | | | | | | | | | | When trying to create a spider table with banned charsets including utf32, utf16, ucs2 and utf16le[1], spider should emit an error immediately, rather than wait until a separate statement that establishes a connection (e.g. SELECT). This also applies to ALTER TABLE statement that changes charsets. [1] https://mariadb.com/kb/en/server-system-variables/#character_set_client Signed-off-by: Yuchen Pei <yuchen.pei@mariadb.com> Reviewed-by: Nayuta Yanagisawa <nayuta.yanagisawa@mariadb.com>
* MDEV-28996 ASAN errors in String::q_append / spider_string::q_append / ↵Nayuta Yanagisawa2022-11-284-9/+90
| | | | | | | spider_db_mbase_util::open_item_func The server crashed due to the stack-use-after-scope on tmp_str. tmp_str will be used later so should not point to the local buffer.
* MDEV-29855 Crash with SPIDER_DIRECT_SQL and spider_udf_ds_use_real_table=1Nayuta Yanagisawa2022-11-244-11/+77
| | | | | | | | | | | | | The crash occurs because of the following call of TABLE_LIST::init_one_table(): table_list.init_one_table( &table_list.db, &table_list.table_name, 0, TL_WRITE); One should not pass table_list.db and table_list.table_name to the function because it update the very members internally. The function is called previously, and there is no need to call it again. So, simply removing the call will resolve the problem.
* MDEV-26852 Spider: -Werror=maybe-uninitialized raises on spd_sys_table.cc ↵Nayuta Yanagisawa2022-09-262-6/+9
| | | | | | | and ha_spider.cc The warning "maybe-uninitialized" raises on spd_sys_table.cc and ha_spider.cc when the sever is compiled with CMAKE_CXX_FLAGS=-Og.
* Backport fix for MDEV-29352 to 10.3-10.5Alexey Botchkov2022-09-213-0/+31
| | | | | | | | | | | | | | | | | The fix for MDEV-29352 was pushed to 10.6+ but the code causing the bug is old and the bug is unlikely to be a recent regression in 10.6. So, we apply the fix also to older versions, 10.3-10.5. The original commit message: MDEV-29352 SIGSEGV's in strlen and unknown location on optimized builds at SHUTDOWN When the UDF creation frails to write the newly created UDF into the related system table, the UDF is still created in memory. However, as it is now, the related DLL is unloaded in this case right in the mysql_create_function. And failure happens when the UDF handle is freed and tries to unload the respective DLL which is still unloaded.
* MDEV-29480 spider group by handler wrong result on order by aggregate aliasSergei Golubchik2022-09-201-0/+2
| | | | | | | | | | | | | | | | | | | | | when generating a query to send to a remote server, spider generates new aliases for all tables in the query (at least in the group_by handler). First it walks all the expressions and create a list of new table aliases to use for each field. Then - in init_scan() - it actually generates the query, taking for each field the next alias from the list. It dives recursively into functions, for example, for func(f1) it'll go in, will see the field f1 and append to the list the new name for the table of f1. This works fine for non-aggregate functions and for aggregate functions in the SELECT list. But aggregate functions in the ORDER BY are always references to the select list, they never need to be qualified with a table name. That is, even if there is a field name as an argument of an aggregate function in the ORDER BY it must not append a table alias to the list. Let's just skip aggregate functions when analyzing ORDER BY for table aliases. This fixes spider/bugfix.mdev_29008 (was observed on aarch64, x86, ppc64le, and amd64 --rr)
* MDEV-29446 Change SHOW CREATE TABLE to display default collationAlexander Barkov2022-09-123-16/+16
|
* MDEV-27172 Prefix indices on Spider tables may lead to wrong query resultsNayuta Yanagisawa2022-09-017-251/+334
| | | | | | | | | | Spider converts HA_READ_KEY_EXACT to the equality (=) in the function spider_db_append_key_where_internal() but the conversion is not necessarily correct for tables with prefix indices. We fix the bug by converting HA_READ_KEY_EXACT to 'LIKE "foo%"' when a target key is a prefix key. The fix is partly inspired by FEDERATED. See ha_federated::create_where_from_key() for more details.
* MDEV-29008 Server crash or assertion `field' failed in ↵Nayuta Yanagisawa2022-08-164-2/+80
| | | | | | | | | | | spider_db_open_item_ident / group by handler ha_spider::field_exchange() returns NULL and that results in a crash or a assertion failure in spider_db_open_item_ident(). In the first place, there seems to be no need to call field_exchange() for printing an identity (column name with alias). Thus, we simply remove the call.
* Fix GCC -Og -Wmaybe-uninitializedMarko Mäkelä2022-07-281-5/+5
|
* MDEV-26544 Assertion `part_share->auto_inc_initialized' failed in ↵Nayuta Yanagisawa2022-07-053-0/+57
| | | | | | | | ha_partition::get_auto_increment on INSERT The partition storage engine ignores return (error) values of handler::info(). As a result, a query that should be aborted is not aborted and then the server violates the assertion.
* MDEV-29011 Server crash in spider_db_open_item_cond with XOR operatorNayuta Yanagisawa2022-07-054-10/+84
| | | | | | Item_func_xor and Item_cond are both derived class of Item_bool_func. Spider converts *Item_func_xor to *Item_cond and then calls the member function argument_list(), which Item_func_xor does not implement.
* MDEV-28854 Disallow INSERT DELAYED on Spider tableHirokazu Hata2022-06-279-35/+71
| | | | | | | | | | | | | | | | | | | | | Spider supports (or at least allows) INSERT DELAYED but the documentation does not specify spider as a storage engine that supports "INSERT DELAYED". Also, although not mentioned in the documentation, "INSERT DELAYED" is not intended to be executed inside a transaction, as can be seen from the list of supported storage engines. The current implementation allows executing a delayed insert on a remote transactional table and this breaks the consistency ensured by the transaction. We too remove "internal_delayed", one of the Spider table parameters. Documentation says, > Whether to transmit existence of delay to remote servers when > executing an INSERT DELAYED statement on local server. This table parameter is only used for "INSERT DELAYED". Reviewed by: Nayuta Yanagisawa
* MDEV-28301 Spider: Fix GCC warnings, comparing the result of pointer ↵Nayuta Yanagisawa2022-05-131-21/+9
| | | | | | addition ... and NULL The condition of the if statements are always true.
* Merge remote-tracking branch 'origin/10.2' into 10.3Alexander Barkov2022-04-143-1/+19
|\
| * MDEV-28225 Disallow user to create Spider temporary tableKiyoshiTakeda2022-04-113-1/+19
| | | | | | | | | | | | | | | | | | | | Creating a temporary table with Spider is non-sense because a Spider table cannot hold any physical data and it requires an additional effort to manage even if it is configured correctly. Set HTON_TEMPORARY_NOT_SUPPORTED to spider_hton->flags. Reviewed-by: nayuta.yanagisawa@hey.com Co-authored-by: d8sk4ueun@gmail.com
| * MDEV-26545 Spider does not correctly handle UDF and stored function in where ↵Daniel Ye2021-09-225-1/+418
| | | | | | | | | | | | 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).
* | MDEV-25116 Spider: IF(COUNT( trigger SQL Error (1054)_ Unknown column '' in ↵Nayuta Yanagisawa2022-04-084-2/+74
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | field list The original query "SELECT IF(COUNT(a.`id`)>=0,'Y','N') FROM t" is transformed to "SELECT COUNT(a.`id`), IF(ref >= 0, 'Y', 'N') FROM t", where ref is Item_ref to "COUNT(a.`id`)", by split_sum_func(). Spider walks the item list twice, invoking spider_db_print_item_type(). The first invocation is in spider_create_group_by_handler() with str == NULL. The second one is in spider_group_by_handler::init_scan() with str != NULL. spider_db_print_item_type() prints nothing at the first invocation, and it prints item at the second invocation. However, at the second invocation, the above mentioned ref to "COUNT(a.`id`)" points to a field in a temporary table where the result will be stored. Thus, to look behind the item_ref, Spider need to generate the query earlier. A possible fix would be to generate a query to send in spider_create_group_by_handler(). However, the fix requires a considerable amount of changes of the Spider's GROUP BY handler. I'd like to avoid that. So, I fix the problem by not to use the GROUP BY handler when a query contains Item_ref whose table_name, name, and alias_name_used are not set.
* | 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-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.
* | 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.
* | 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`.
* | 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).
* | 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
| |
* | Fix GCC -Wstringop-truncationMarko Mäkelä2020-03-301-0/+1
| |
* | Merge branch '10.2' into 10.3Oleksandr Byelkin2019-12-041-1/+1
|\ \ | |/
* | Merge remote-tracking branch 10.2 into 10.3Jan Lindström2019-12-024-1/+218
|\ \ | |/ | | | | | | | | | | | | | | Conflicts: mysql-test/suite/galera/t/galera_binlog_event_max_size_max-master.opt mysql-test/suite/innodb/r/innodb-mdev-7513.result mysql-test/suite/innodb/t/innodb-mdev-7513.test mysql-test/suite/wsrep/disabled.def storage/innobase/ibuf/ibuf0ibuf.cc
| * MDEV-17508 Fix bug for spider when using "not like"willhan2019-11-254-1/+218
| | | | | | | | | | | | | | | | | | | | | | | | | | | | fix bug for spider where using "not like" (#890) test case: t1 is a spider engine table; CREATE TABLE `t1` ( `id` int(11) NOT NULL DEFAULT '0', `name` char(64) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=SPIDER query: "select * from t1 where name not like 'x%' " would dispatch "select xxx name name like 'x%' " to remote mysqld, is wrong
| * Merge 10.1 into 10.2Eugene Kosov2019-07-091-1/+1
| |\
| | * imporve clang buildEugene Kosov2019-06-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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-19238 Mariadb spider - crashes on where nullOleksandr Byelkin2019-10-095-0/+200
| | | | | | | | | | | | (fix and explanation came with MDEV-20753 (duplicate of this bug))
* | | Fix CMake warning in spider, in Windows ninja buildVladislav Vaintroub2019-09-121-0/+3
| | |
View Lorry Controller Status