summaryrefslogtreecommitdiff
path: root/sql
Commit message (Collapse)AuthorAgeFilesLines
* MDEV-13467 fixup: Improve error handlingMarko Mäkelä2021-04-081-7/+15
|
* MDEV-25294 signal handler display coredump on macDavid CARLIER2021-03-301-1/+13
|
* MDEV-24923 : Port selected Galera conflict resolution changes from 10.6Jan Lindström2021-03-301-10/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add condition on trx->state == TRX_STATE_COMMITTED_IN_MEMORY in order to avoid unnecessary work. If a transaction has already been committed or rolled back, it will release its locks in lock_release() and let the waiting thread(s) continue execution. Let BF wait on lock_rec_has_to_wait and if necessary other BF is replayed. wsrep_trx_order_before If BF is not even replicated yet then they are ordered correctly. bg_wsrep_kill_trx Make sure victim_trx is found and check also its state. If state is TRX_STATE_COMMITTED_IN_MEMORY transaction is already committed or rolled back and will release it locks soon. wsrep_assert_no_bf_bf_wait Transaction requesting new record lock should be TRX_STATE_ACTIVE Conflicting transaction can be in states TRX_STATE_ACTIVE, TRX_STATE_COMMITTED_IN_MEMORY or in TRX_STATE_PREPARED. If conflicting transaction is already committed in memory or prepared we should wait. When transaction is committed in memory we held trx mutex, but not lock_sys->mutex. Therefore, we could end here before transaction has time to do lock_release() that is protected with lock_sys->mutex. lock_rec_has_to_wait We very well can let bf to wait normally as other BF will be replayed in case of conflict. For debug builds we will do additional sanity checks to catch unsupported bf wait if any. wsrep_kill_victim Check is victim already in TRX_STATE_COMMITTED_IN_MEMORY state and if it is we can return. lock_rec_dequeue_from_page lock_rec_unlock Remove unnecessary wsrep_assert_no_bf_bf_wait function calls. We can very well let BF wait here.
* mallinfo2: whitespace fixDaniel Black2021-03-301-1/+1
|
* MDEV-13467: Feature request: Support for ST_Distance_Sphere()bb-10.2-anel-MDEV-13467-gis-feature-v1Anel Husakovic2021-03-271-2/+2
| | | | | - jump to label ‘handle_errors’ can enter to the scope of non-POD ‘Geometry_buffer buffer2’
* MDEV-25272: Wrong function name in error messages upon ST_GeomFromGeoJSON callAnel Husakovic2021-03-271-2/+2
| | | | - Invalid function name during ER_WRONG_VALUE_FOR_TYPE and ER_GIS_INVALID_DATA
* MDEV-13467: Feature request: Support for ST_Distance_Sphere()Anel Husakovic2021-03-275-3/+399
| | | | | | | | - Cherry-pick 51e48b9f8981 - vscode gitignore - Thanks Robin Dupret for the review. Reviewed by:daniel@mariadb.org holyfoot@mariadb.com
* Replace mallinfo with mallinfo2 on supported systemsMichael Okoko2021-03-271-2/+6
| | | | | | | `mallinfo` is deprecated since glibc 2.33 and has been replaced by mallinfo2. The deprecation causes building the server to fail if glibc version is > 2.33. Check if mallinfo2 exist on the system and use it instead.
* MDEV-24767 Wrong result when forced BNLH is used for join supportedIgor Babaev2021-03-221-1/+1
| | | | | | | | | | | | by compound index This typo bug may lead to wrong result sets for equi-join queries where the join operation is supported by a compound index such that the order of its components differs from the order of the corresponding columns in the table the index belongs to. The bug manifests itself only when usage of the BNLH algorithm is forced. The fix for the bug was provided by Chu Huaxing.
* MDEV-25112 MIN/MAX aggregation over an indexed column may return wrong resultIgor Babaev2021-03-181-0/+3
| | | | | | | | | | | | | | | | | If a query with implicit grouping contains in MIN/MAX set function in the select list over a column that is a part of an index then the query might be subject to MIN/MAX optimization. With this optimization the server performs a look-up into an index, fetches a value of the column C used in the MIN/MAX function and substitute the MIN/MAX expression for this value. This allows to eliminate the table containing C from further join processing. In order the optimization to be applied the WHERE condition must be a conjunction of simple equality/inequality predicates or/and BETWEEN predicates. The bug fixed in the patch resulted in fetching a wrong value from the index used for MIN/MAX optimization. It may happened when a BETWEEN predicate containing the MIN/MAX value followed a strict inequality. Approved by dmitry.shulga@mariadb.com
* MDEV-24916 : Assertion `current_stmt_binlog_format == BINLOG_FORMAT_STMT || ↵Jan Lindström2021-03-181-8/+12
| | | | | | | | current_stmt_binlog_format == BINLOG_FORMAT_ROW' failed in THD::is_current_stmt_binlog_format_row Store old value of binlog format before wsrep code so that if we bail out because wsrep is not ready for connections we can restore binlog format correctly.
* MDEV-24519: Server crashes in Charset::set_charset upon SELECTVarun Gupta2021-03-125-16/+78
| | | | | | | | | | | | | | | | | | | | | | | | | | The query causing the issue here has implicit grouping for we have to produce one row with special values for the aggregates (depending on each aggregate function), and NULL values for all non-aggregate fields. The subselect item where implicit grouping was being done, null_value for the subselect item was not being set for the case when the implicit grouping produces NULL values for the items in the select list of the subquery. This which was leading to the crash. The fix would be to set the null_value when all the values for the row column have NULL values. Further changes are 1) etting null_value for Item_singlerow_subselect only after val_* functions have been called. 2) Introduced a parameter null_value_inside to Item_cache that would store be set to TRUE if any of the arguments of the Item_cache are null. Reviewed And co-authored by Monty
* Update sponsorsIan Gilfillan2021-03-121-9/+4
|
* MDEV-24597 Explicit column name error in CTE of UNIONIgor Babaev2021-03-101-0/+1
| | | | | | | | | | | | | | | This bug manifested itself when executing queries with multiple reference to a CTE specified by a query expression with union and having its column names explicitly declared. In this case the server returned a bogus error message about unknown column name. It happened because while for the first reference to the CTE the names of the columns returned by the CTE specification were properly changed to match the CTE definition for the other references it was not done. This was a consequence of not quite complete code of the function With_element::clone_parsed_spec() that forgot to set the reference to the CTE definition for unit structures representing non-first CTE references. Approved by dmitry.shulga@mariadb.com
* MDEV-21104 Wrong result (extra rows and wrong values) with incremental BNLHIgor Babaev2021-03-102-11/+88
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This bug could affect multi-way join queries with embedded outer joins that contained a conjunctive IS NULL predicate over a non-nullable column from inner table of an outer join. The predicate could occur in WHERE condition or in ON condition. Due to this bug a wrong result set could be returned by the query. The bug manifested itself only when join buffers were employed for join operations. The problem appeared because - a bug in the function JOIN_CACHE::get_match_flag_by_pos that not always returned proper match flags for embedding outer joins stored together with table rows put a join buffer. - bug in the function JOIN_CACHE::join_matching_records that not always correctly determined that a row from the buffer could be skipped due to applied 'not_exists' optimization. Example: SELECT * FROM t1 LEFT JOIN ((t2 LEFT JOIN t3 ON c = d) JOIN t4) ON b = e WHERE e IS NULL; The patch introduces a new function that finds the match flag for a record from join buffer specifying the buffer where this flag has to be found. The function is called JOIN_CACHE::get_match_flag_by_pos_from_join_buffer(). Now this function rather than JOIN_CACHE::get_match_flag_by_pos() is used in JOIN_CACHE::skip_if_matched() to check whether a record from the join buffer must be ignored when extending the record by null complements. Also the code of the function JOIN_CACHE::skip_if_not_needed_match() has been changed. The function checks whether a record from the join buffer still may produce some useful extensions. Also some clarifying comments has been added. Approved by monty@mariadb.com.
* MDEV-25002 ON expressions cannot contain outer referencesIgor Babaev2021-03-091-0/+2
| | | | | | | | | | | | | | | A bogus error message was issued for any outer references occurred in ON expressions used in subqueries. This prevented execution of queries containing subqueries as soon as they used outer references in their ON clauses. This happened because the Name_resolution_context structure created for any ON expression erroneously had the field outer_context set to NULL. The fields select_lex of this structure was not set correctly either. The idea of the fix was taken from mysql code of the function push_new_name_resolution_context(). Approved by dmitry.shulga@mariadb.com
* Correct the value of global memory_usedSergei Golubchik2021-03-083-12/+21
| | | | | | | As a special hack global memory_used isn't SHOW_LONG_STATUS but still relies on calc_sum_of_all_status() being called. followup for 63f91927870
* MDEV-24853: Duplicate key generated during cluster configuration changeJulius Goryavsky2021-03-083-30/+0
| | | | | | | | | | | | | | | | | Incorrect processing of an auto-incrementing field in the WSREP-related code during applying transactions results in a duplicate key being created. This is due to the fact that at the beginning of the write_row() and update_row() functions, the values of the auto-increment parameters are used, which are read from the parameters of the current thread, but further along the code other values are used, which are read from global variables (when applying a transaction). This can happen when the cluster configuration has changed while applying a transaction (for example in the high_priority_service mode for Galera 4). Further during IST processing duplicating key is detected, and processing of the DB_DUPLICATE_KEY return code (inside innodb, in the write_row() handler) results in a call to the wsrep_thd_self_abort() function.
* MDEV-25032: Window functions without column references get removed from ORDER BYVicențiu Ciorbaru2021-03-041-0/+1
| | | | | | | | | | | | | row_number() over () window function can be used without any column in the OVER clause. Additionally, the item doesn't reference any tables, as it's not effectively referencing any table. Rather it is specifically built based on the end temporary table used for window function computation. This caused remove_const function to wrongly drop it from the ORDER list. Effectively, we shouldn't be dropping any window function from the ORDER clause, so adjust remove_const to account for that. Reviewed by: Sergei Petrunia sergey@mariadb.com
* MDEV-24532 Table corruption ER_NO_SUCH_TABLE_IN_ENGINE .. on table with ↵Monty2021-03-022-0/+15
| | | | | | | | | | | | | | | | | | | | | | foreign key When doing a truncate on an Innodb under lock tables, InnoDB would rename the old table to #sql-... and recreate a new 't1' table. The table lock would still be on the #sql-table. When doing ALTER TABLE, Innodb would do the changes on the #sql table (which would disappear on close). When the SQL layer, as part of inline alter table, would close the original t1 table (#sql in InnoDB) and then reopen the t1 table, Innodb would notice that this does not match it's own (old) t1 table and generate an error. Fixed by adding code in truncate table that if we are under lock tables and truncating an InnoDB table, we would close, reopen and lock the table after truncate. This will remove the #sql table and ensure that lock tables is using the new empty table. Reviewer: Marko Mäkelä
* MDEV-25006: Failed assertion on executing EXPLAIN DELETE statement as a ↵Dmitry Shulga2021-03-021-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | prepared statement Attempt to execute EXPLAIN statement on multi-table DELETE statement leads to firing firing of the assertion DBUG_ASSERT(! is_set()); in the method Diagnostics_area::set_eof_status. For example, above mentioned assertion failure happens in case any of the following statements EXPLAIN DELETE FROM t1.* USING t1 EXPLAIN DELETE b FROM t1 AS a JOIN t1 AS b are executed in prepared statement mode provided the table t1 does exist. This assertion is hit by the reason that a status of Diagnostics_area is set twice. The first time it is set from the function do_select() when the method multi_delete::send_eof() called. The second time it is set when the method Explain_query::send_explain() calls the method select_send::send_eof (this method invokes the method Diagnostics_area::set_eof_status that finally hits assertion) The second invocation for a setter method of the class Diagnostics_area is correct and run to send a response containing explain data. But first invocation of a setter method of the class Diagnostics_area is wrong since the function do_select() shouldn't be called at all for handling of the EXPLAIN statement. The reason by that the function do_select() is called during handling of the EXPLAIN statement is that the flag SELECT_DESCRIBE not set in the data member JOIN::select_options. The flag SELECT_DESCRIBE if is copied from values select_lex->options. During parsing of EXPLAIN statement this flag is set but latter reset from the function reinit_stmt_before_use() that is called on execution of prepared statement. void reinit_stmt_before_use(THD *thd, LEX *lex) { ... for (; sl; sl= sl->next_select_in_list()) { if (sl->changed_elements & TOUCHED_SEL_COND) { /* remove option which was put by mysql_explain_union() */ sl->options&= ~SELECT_DESCRIBE; ... } ... } So, to fix the issue the flag SELECT_DESCRIBE is set forcibly at the mysql_select() function in case thd->lex->describe set, that is in case EXPLAIN being executed.
* MDEV-24860: Incorrect behaviour of SET STATEMENT in case it is executed as a ↵Dmitry Shulga2021-02-253-120/+164
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | prepared statement Running statements with SET STATEMENT FOR clause is handled incorrectly in case the whole statement is executed in prepared statement mode. For example, running of the following statement SET STATEMENT sql_mode = 'NO_ENGINE_SUBSTITUTION' FOR CREATE TABLE t1 AS SELECT CONCAT('abc') AS c1; results in different definition of the table t1 depending on whether the statement is executed as a prepared or as a regular statement. In first case the column c1 is defined as `c1` varchar(3) DEFAULT NULL in the last case the column c1 is defined as `c1` varchar(3) NOT NULL Different definition for the column c1 arise due to the fact that a value of the data memeber Item_func_concat::maybe_null depends on whether strict mode is on or off. Below is definition of the method fix_fields() of the class Item_str_func that is base class for the class Item_func_concat that is created on parsing the SET STATEMENT FOR clause. bool Item_str_func::fix_fields(THD *thd, Item **ref) { bool res= Item_func::fix_fields(thd, ref); /* In Item_str_func::check_well_formed_result() we may set null_value flag on the same condition as in test() below. */ maybe_null= maybe_null || thd->is_strict_mode(); return res; } Although the clause SET STATEMENT sql_mode = 'NO_ENGINE_SUBSTITUTION' FOR is parsed on PREPARE phase during processing of the prepared statement, real setting of the sql_mode system variable is done on EXECUTION phase. On the other hand, the method Item_str_func::fix_fields is called on PREPARE phase. In result, thd->is_strict_mode() returns true during calling the method Item_str_func::fix_fields(), the data member maybe_null is assigned the value true and column c1 is defined as DEFAULT NULL. To fix the issue the system variables listed in the SET STATEMENT FOR clause are set at the beginning of handling the PREPARE phase just right before calling the function check_prepared_statement() and their original values restored immediate after return from this function. Additionally, to avoid code duplication the source code used in the function mysql_execute_command for setting variables, specified by SET STATEMENT clause, were extracted to the standalone functions run_set_statement_if_requested(). This new function is called from the function mysql_execute_command() and the method Prepared_statement::prepare().
* cleanup: stat tablesSergei Golubchik2021-02-221-30/+24
| | | | | | | don't allocate Column_statistics_collected objects that won't be used. minor style fixes (StringBuffer<>, etc)
* MDEV-23753: SIGSEGV in Column_stat::store_stat_fieldsSergei Golubchik2021-02-221-7/+5
| | | | | | | | | | | | only collect persistent stats for columns explicitly listed by the user in the ANALYZE TABLE PERSISTENT FOR COLUMNS (...) clause. The engine can extend table->read_set as much as it wants, it should not affect the collected statistics. Test case from the 3b94309a6c applies - it used to crash, because ha_partition extended table->read_set after the loop that initialized some objects based on bits in the read_set but before the loop that used these objects based on bits in the read_set.
* Revert "MDEV-23753: SIGSEGV in Column_stat::store_stat_fields"Sergei Golubchik2021-02-221-4/+0
| | | | | | | | | This reverts the commit 3b94309a6c but keeps the test Because the fix is a hack that isn't supposed to do anything, and relies on a side-effect of rnd_init inside ha_partition. A different fix is coming up.
* Merge branch 'bb-10.2-release' into 10.2Sergei Golubchik2021-02-222-5/+9
|\
| * make @@wsrep_provider and @@wsrep_notify_cmd read-onlymariadb-10.2.37Sergei Golubchik2021-02-181-2/+2
| | | | | | | | this should simplify run-time cluster management
| * don't allocate 64K on the stackSergei Golubchik2021-02-181-3/+7
| |
* | MDEV-24872 : galera.galera_insert_multi MTR failed: crash with SIGABRTJan Lindström2021-02-171-2/+4
| | | | | | | | | | Problem was that we tried to lock THD::LOCK_thd_data after we have acquired lock_sys mutex. This is against mutex ordering rules.
* | MDEV-23291: SUM column from a derived table returns invalid valuesVarun Gupta2021-02-162-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | The issue here was the read_set bitmap was not set for a field which was used as a reference in an inner select. We need to make sure that if we are in an inner select and we have references from outer select then we update the table bitmaps for such references. Introduced a function in the class Item_subselect that would update bitmaps of table for the references within a subquery that are defined in outer selects.
* | MDEV-24779: main.subselect fails in buildbot with --ps-protocolVarun Gupta2021-02-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Follow-up fix to commit 26f5033(MDEV-23449) The GROUP BY clause inside IN/ALL/ANY subquery is removed when there is no aggregate function or HAVING clause in the subquery. When the GROUP BY clause is removed, a subquery can also be removed if it part of the GROUP BY clause. This is done inside the function remove_redundant_subquery_clauses. Here we walk over the GROUP BY list and remove a subselect from its unit via the callback function eliminate_subselect_processor. The issue here was that when the query was being re-executed it was trying to reinitialize the select that was removed as stated above. This is not required, so the fix would be to remove select_lex both from tree lex structure and the global list of nodes so that we don't do the reinitialization again.
* | MDEV-19474: Histogram statistics are used even with ↵Varun Gupta2021-02-162-4/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | optimizer_use_condition_selectivity=3 The issue here was histogram statistics were being used even when the level of optimizer_use_condition_selectivity doesn't allow usage of statistics from histogram. The histogram statistics are read for a table only when optimizer_use_condition_selectivity > 3. But the TABLE structure can be stored in the internal table cache and be reused for the next query. So in this case the histogram statistics will be available for the next query. The fix would be to make sure to use the histogram statistics only when optimizer_use_condition_selectivity > 3.
* | MDEV-19950: Galera test failure on galera_ssl_upgradeJulius Goryavsky2021-02-111-10/+52
| | | | | | | | | | | | | | | | | | | | The test requires adaptation for MariaDB, which is done in this patch. In addition, this patch includes a fix for the SST script startup code that adds escaping for special characters on the command line (in case they are contained in the arguments to mysqld). The fix does not require separate tests, as the required tests are already part of the mtr suite for Galera.
* | MDEV-22741: *SAN: ERROR: AddressSanitizer: use-after-poison on address in ↵Sujatha2021-02-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | instrings/strmake.c:36 from change_master (on optimized builds) Problem: ======== CHANGE MASTER TO MASTER_USER='root', MASTER_SSL=0, MASTER_SSL_CA='', MASTER_SSL_CERT='', MASTER_SSL_KEY='', MASTER_SSL_CRL='', MASTER_SSL_CRLPATH=''; CHANGE MASTER TO MASTER_USER='root', MASTER_PASSWORD='', MASTER_SSL=0; use-after-poison is reported for lex_mi->ssl_crl File: sql_repl.cc if (lex_mi->ssl_crl) strmake_buf(mi->ssl_crl, lex_mi->ssl_crl); Analysis: ======== At the end of CHANGE MASTER statement execution, the LEX_MASTER_INFO parameters are reset so that the next query will have a clean state. But 'ssl_crl' and 'ssl_crl_path' members of LEX_MASTER_INFO object are not cleared during 'LEX_MASTER_INFO::reset'. Hence when a new CHANGE MASTER statement is executed, the stale value of lex_mi->ssl_crl is used, so ASAN reports use-after-poison. Fix: === Clear 'ssl_crl' and 'ssl_crl_path' as part of 'reset'.
* | MDEV-23449: alias do not exist and a query do not report an errorVarun Gupta2021-01-311-16/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | For an IN/ANY/ALL subquery without an aggregate function and HAVING clause, the GROUP BY clause is removed. Due to the GROUP BY list being removed, the invalid reference in the GROUP BY clause was never resolved. Remove the GROUP BY list only when the all the items in the GROUP BY list are resolved. Also removing the GROUP BY list later would not affect the extension that allows using non-aggregated field in an aggregate function (when ONLY_FULL_GROUP_BY is not set) because the GROUP BY list is removed only when their is NO aggregate function in IN/ALL/ANY subquery.
* | MDEV-22583: Selectivity for BIT columns in filtered column for EXPLAIN is ↵Varun Gupta2021-01-301-8/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | incorrect For BIT columns when EITS is collected, we store the integral value in text representation in the min and max fields of the statistical table When this value is retrieved from the statistical table to original table field then we try to store the text representation in the original field which is INCORRECT. The value that is retrieved should be converted to integral type and that value should be stored back in the original field. This would get us the correct estimate for selectivity of the predicate.
* | MDEV-11172: EXPLAIN shows non-sensical value for key_len with type=indexVarun Gupta2021-01-303-4/+10
|/ | | | | | | | | | | | The issue happens when the secondary keys are extended with primary key parts. Inside the function TABLE_SHARE::init_from_binary_frm_image() adds the length bytes for the primary key key parts to the length of the secondary key. This is not needed because when the extended keys are used we recalculate the length for the used key parts. Also removed TABLE_SHARE::total_key_length as it is not used in the code Apporved-by: Monty <monty@mariadb.org>
* ASAN heap-use-after-free in Item_exists_subselect::is_top_level_itemOleksandr Byelkin2021-01-291-1/+3
| | | | check that we can do type casting
* MDEV-22251: get_key_scans_params: Conditional jump or move depends on ↵Sergei Petrunia2021-01-281-0/+1
| | | | | | | | | | | | uninitialised value Apply the patch based on the patch by Varun Gupta: PARAM::is_ror_scan might be used unitialized when check_quick_select() is invoked for a "degenerate" SEL_ARG tree (e.g. one having type SEL_ARG::IMPOSSIBLE). Make check_quick_select() always initialize PARAM::is_ror_scan.
* MDEV-20717 : Plugin system variables and activation options can break ↵Jan Lindström2021-01-281-4/+15
| | | | | | | | | "mysqld --wsrep_recover" Problem is that not all plugins are loaded when wsrep_recover is executed. Thus, we allow unknown system variables and extra system variables during wsrep_recover. Any unknown system variables would still be caught when the server starts up normally after the SST.
* MDEV-24509 : Warning: Memory not freed: 56 on SET @@global.wsrep_sst_authJan Lindström2021-01-262-0/+10
| | | | | It seems that memory is not freed when updated value is NULL or when wsrep is not initialized before shutdown.
* MDEV-23328 Server hang due to Galera lock conflict resolutionSergei Golubchik2021-01-241-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | mutex order violation here. when wsrep bf thread kills a conflicting trx, the stack is wsrep_thd_LOCK() wsrep_kill_victim() lock_rec_other_has_conflicting() lock_clust_rec_read_check_and_lock() row_search_mvcc() ha_innobase::index_read() ha_innobase::rnd_pos() handler::ha_rnd_pos() handler::rnd_pos_by_record() handler::ha_rnd_pos_by_record() Rows_log_event::find_row() Update_rows_log_event::do_exec_row() Rows_log_event::do_apply_event() Log_event::apply_event() wsrep_apply_events() and mutexes are taken in the order lock_sys->mutex -> victim_trx->mutex -> victim_thread->LOCK_thd_data When a normal KILL statement is executed, the stack is innobase_kill_query() kill_handlerton() plugin_foreach_with_mask() ha_kill_query() THD::awake() kill_one_thread() and mutexes are victim_thread->LOCK_thd_data -> lock_sys->mutex -> victim_trx->mutex To fix the mutex order violation we kill the victim thd asynchronously, from the manager thread
* cleanup: void hton::abort_transaction()Sergei Golubchik2021-01-241-1/+1
| | | | | | | and void wsrep_innobase_kill_one_trx() as their return values are never used. Also remove redundant cast and checks that are always true
* cleanup: remove slave background thread, use handle_manager thread insteadSergei Golubchik2021-01-243-156/+35
|
* cleanup: fix and generalize handle_manager threadSergei Golubchik2021-01-242-48/+41
| | | | | | | | | | | | | | | * provide an argument to the callback * don't ignore a callback request if it's already present in the queue * initialize mutex/cond/in_use flag before starting the thread, in case the first callback queueing request arrives before handle_manager had time to initialize * set/check abort_manager under a mutex, otherwise handle_manager thread might destroy LOCK_manager before stop_handle_manager released it * signal COND on queueing a callback, stop cond_wait on callback request * always start the thread, even if flush_time is 0 * but keep the old behavior in embedded (no replication, no galera) * style cleanups (e.g. remove volatile for a variable protected by a mutex)
* don't allow `KILL QUERY ID USER xxx`Sergei Golubchik2021-01-241-7/+11
|
* MDEV-10272: add master host/port info to slave thread exit messagesDaniel Black2021-01-221-0/+5
| | | | | | | | | | | | | Sample log error message generated: 2021-01-21 2:33:24 139912137520896 [Note] Slave SQL thread exiting, replication stopped in log 'master-bin.000001' at position 369 33:24 139912137520896 [Note] master was 127.0.0.1:16400 2021-01-21 2:33:24 139912137828096 [Note] Slave I/O thread exiting, read up to log 'master-bin.000001', position 369 2021-01-21 2:33:24 139912137828096 [Note] master was 127.0.0.1:16400 Based on work by Hartmut Holzgraefe. Reviewer: knielsen@knielsen-hq.org, Andrei, Sachin
* MDEV-8134: The relay-log is not flushed after the slave-relay-log.999999 showedSujatha2021-01-214-4/+23
| | | | | | | | | | | | | | | | | | | | | | Problem: ======== Auto purge of relaylogs stops when relay-log-file is 'slave-relay-log.999999' and slave_parallel_threads is enabled. Analysis: ========= The problem is that in Relay_log_info::inc_group_relay_log_pos() function, when two log names are compared via strcmp() function, it gives correct result, when log name sequence numbers are of same digits(6 digits), But when the number goes to 7 digits, a 999999 compares greater than 1000000, which is wrong, hence the bug. Fix: ==== Extract the numeric extension part of the file name, convert it into unsigned long and compare. Thanks to David Zhao for the contribution.
* MDEV-16940 Server crashes in unsafe_key_update upon attempt to update viewIgor Babaev2021-01-192-0/+6
| | | | | | | | | | | | | | | | through 2nd execution of SP This bug caused a server crash on the second call of any stored procedure that contained an UPDATE statement over a multi-table view reporting an error message at the prepare stage. On the first call of the stored procedure after reporting an error at the preparation stage of the UPDATE statement finished without calling the function SELECT_LEX::save_prep_leaf_tables() for the SELECT used as the definition of the view. This left the SELECT_LEX structure used by the UPDATE statement in an inconsistent state for second call of the stored procedure. Approved by Oleksandr Byelkin <sanja@mariadb.com>
* MDEV-19723 Assertion `je->state == JST_KEY' failed while SELECT ↵Alexey Botchkov2021-01-191-0/+1
| | | | | | ST_GEOMFROMGEOJSON() and Assertion `!mysql_bin_log.is_open() || thd.is_current_stmt_binlog_format_row()' The invalid GeoJSON case wasn't handled here.
View Lorry Controller Status