summaryrefslogtreecommitdiff
path: root/sql/handler.cc
Commit message (Collapse)AuthorAgeFilesLines
* MDEV-18428 Memory: If transactional=0 is specified in CREATE TABLE, it is ↵Sergei Golubchik2021-01-111-0/+1
| | | | | | | | | | | | | | not possible to ALTER TABLE * be strict in CREATE TABLE, just like in ALTER TABLE, because CREATE TABLE, just like ALTER TABLE, can be rolled back for any engine * but don't auto-convert warnings into errors for engine warnings (handler::create) - this matches ALTER TABLE behavior * and not when creating a default record, these errors are handled specially (and replaced with ER_INVALID_DEFAULT) * always issue a Note when a non-unique key is truncated, because it's not a Warning that can be converted to an Error. Before this commit it was a Note for blobs and a Warning for all other data types.
* MDEV-23536 Race condition between KILL and transaction commitSergei Golubchik2021-01-111-0/+1
| | | | | | | | | | | | Server part: kill_handlerton() was accessing thd->ha_data[] for some other thd, while it could be concurrently modified by its owner thd. protect thd->ha_data[] modifications with a mutex. require this mutex when accessing thd->ha_data[] from kill_handlerton. InnoDB part: on close_connection, detach trx from thd before freeing the trx
* MDEV-23209: Assertion `!is_set() || (m_status == DA_OK_BULK && is_bulk_op())'Rucha Deodhar2020-12-151-0/+7
| | | | | | | | | failed in Diagnostics_area::set_ok_status on INSERT Analysis: Error is not returned when strict mode is enabled and value is truncated because double is outside range. Fix: Return HA_ERR_AUTOINC_ERANGE if the error was reported when double is outside range.
* Merge 10.1 into 10.2Marko Mäkelä2020-10-211-0/+1
|\
| * MDEV-23938: innodb row_search_idx_cond_check handle ICP_ABORTED_BY_USERSergei Petrunia2020-10-161-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | - row_search_mvcc() should return DB_INTERRUPTED when it got killed. - Add a syncpoint for the ICP check. - Add test coverage for killed-during-ICP-check scenario Backport of MDEV-22761 fixes for ICP from 10.4 commits: * a6f956488c712bef3b13660584d1b905e0c676cc * c03885cd9ceb1ede7f49a9e218022b401b3a1e28 XtraDB was fixed in deb3b9a17498 Reviewer: Daniel Black
* | Merge branch '10.1' into 10.2Oleksandr Byelkin2020-08-021-6/+6
|\ \ | |/
| * Code comment spellfixesIan Gilfillan2020-07-221-6/+6
| |
| * 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.
* | Fixed crash in aria recovery when using bulk insertMonty2020-05-261-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MDEV-20578 Got error 126 when executing undo undo_key_delete upon Aria crash recovery The crash happens in this scenario: - Table with unique keys and non unique keys - Batch insert (LOAD DATA or INSERT ... SELECT) with REPLACE - Some insert succeeds followed by duplicate key error In the above scenario the table gets corrupted. The bug was that we don't generate any undo entry for the failed insert as the whole insert can be ignored by undo. The code did however not take into account that when bulk insert is used, we would write cached keys to the file on failure and undo would wrongly ignore these. Fixed by moving the writing of the cache keys after we write the aborted-insert event to the log.
* | MDEV-21168: Active XA transactions stop slave from working after backupVlad Lesin2020-04-071-14/+20
| | | | | | | | | | | | | | | | | | was restored. Optionally rollback prepared XA's on "mariabackup --prepare". The fix MUST NOT be ported on 10.5+, as MDEV-742 fix solves the issue for slaves.
* | Merge 10.1 into 10.2Marko Mäkelä2019-06-121-0/+34
|\ \ | |/
| * MDEV-19653 Add class Sql_cmd_create_tableAlexander Barkov2019-05-311-0/+34
| |
* | MDEV-19158: MariaDB 10.2.22 is writing duplicate entries into binary logSujatha2019-05-141-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem: ======== We have a Master/Master Setup on two servers, but are only writing to one of those servers (so it is essentially Master/Slave) We upgraded from 10.1.* to 10.2.22 last week and starting with the upgrade, we are getting duplicate key errors on the slave. BINLOG=mixed. Analysis: ========= This issue happens with LOCK TABLES and binlog_format=MIXED combination. When an UNSAFE statement is encountered in 'MIXED' mode, it is logged in the form of 'ROW' format. For all the tables that are part of LOCK TABLES list their table maps are written into the binary log. For each table in the list a check is done to see if 'check_table_binlog_row_based_done' flag is set or not. If it is not set a check process is initiated to see if table qualifies for row based binary logging or not and 'check_table_binlog_row_based_done' is set. This flag will be cleared at the time of closing thread tables. But there can be special cases where the LOCK TABLES contains more number of tables but the unsafe query is actually using subset of tables from LOCK TABLES list. For example: LOCK TABLES locks t1,t2,t3 but the unsafe statement makes use of only two tables t1,t3. In this case the 'check_table_binlog_row_based_done' flag is enabled for table 't2' while writing table map, but 'close_thread_tables' function call will not reset this flag. Since the flag is not cleared for table 't2' even a safe statement which used t2 will be logged in the form of row based format. This leads to an assert on debug builds and causes duplicate entries in release builds. In release builds a statement is logged in the form of both ROW and STATEMENT format. This causes the slave to fail with duplicate key error. Fix: === During 'close_thread_tables' when LOCK TABLE modes are active "ha_reset" is done for all the tables which were part of current statement. As mentioned in the example 'ha_reset' is called for tables 't1' and 't3'. This will clear the 'check_table_binlog_row_based_done' flag. At this point add a check for the rest of the tables to see if 'check_table_binlog_row_based_done' is enabled or not. If enabled clear the flag.
* | Merge 10.1 into 10.2Marko Mäkelä2019-05-131-2/+2
|\ \ | |/
| * Merge branch '5.5' into 10.1Vicențiu Ciorbaru2019-05-111-2/+2
| |\
| | * Follow-up to changing FSF addressVicențiu Ciorbaru2019-05-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some places didn't match the previous rules, making the Floor address wrong. Additional sed rules: sed -i -e 's/Place.*Suite .*, Boston/Street, Fifth Floor, Boston/g' sed -i -e 's/Suite .*, Boston/Fifth Floor, Boston/g'
* | | MDEV-16240: Assertion `0' failed in row_sel_convert_mysql_key_to_innobasebb-10.2-MDEV-16240Oleksandr Byelkin2019-04-251-2/+13
| | | | | | | | | | | | Set table in row ID position mode before using this function.
* | | Merge 10.1 into 10.2Marko Mäkelä2019-04-251-0/+1
|\ \ \ | |/ /
| * | Merge 5.5 into 10.1Marko Mäkelä2019-04-241-0/+1
| |\ \ | | |/
| | * MDEV-15772 Potential list overrun during XA recoveryThirunarayanan Balathandayuthapani2019-04-241-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | InnoDB could return the same list again and again if the buffer passed to trx_recover_for_mysql() is smaller than the number of transactions that InnoDB recovered in XA PREPARE state. We introduce the transaction state TRX_PREPARED_RECOVERED, which is like TRX_PREPARED, but will be set during trx_recover_for_mysql() so that each transaction will only be returned once. Because init_server_components() is invoking ha_recover() twice, we must reset the state of the transactions back to TRX_PREPARED after returning the complete list, so that repeated traversals will see the complete list again, instead of seeing an empty list. Without this tweak, the test main.tc_heuristic_recover would hang in MariaDB 10.1.
* | | Merge remote-tracking branch 'origin/10.1' into 10.2Jan Lindström2019-02-281-13/+25
|\ \ \ | |/ /
| * | Revert offending part of MDEV-9519: Data corruption will happen on the ↵Jan Lindström2019-02-281-13/+25
| | | | | | | | | | | | | | | | | | | | | Galera cluster size change This will allow test binlog.binlog_stm_binlog to pass more often. Note that this is not a real fix to that test failure.
| * | MDEV-9519: Data corruption will happen on the Galera cluster size changeJulius Goryavsky2019-02-251-14/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we have a 2+ node cluster which is replicating from an async master and the binlog_format is set to STATEMENT and multi-row inserts are executed on a table with an auto_increment column such that values are automatically generated by MySQL, then the server node generates wrong auto_increment values, which are different from what was generated on the async master. In the title of the MDEV-9519 it was proposed to ban start slave on a Galera if master binlog_format = statement and wsrep_auto_increment_control = 1, but the problem can be solved without such a restriction. The causes and fixes: 1. We need to improve processing of changing the auto-increment values after changing the cluster size. 2. If wsrep auto_increment_control switched on during operation of the node, then we should immediately update the auto_increment_increment and auto_increment_offset global variables, without waiting of the next invocation of the wsrep_view_handler_cb() callback. In the current version these variables retain its initial values if wsrep_auto_increment_control is switched on during operation of the node, which leads to inconsistent results on the different nodes in some scenarios. 3. If wsrep auto_increment_control switched off during operation of the node, then we must return the original values of the auto_increment_increment and auto_increment_offset global variables, as the user has set. To make this possible, we need to add a "shadow copies" of these variables (which stores the latest values set by the user). https://jira.mariadb.org/browse/MDEV-9519
* | | MDEV-9519: Data corruption will happen on the Galera cluster size changeJulius Goryavsky2019-02-261-14/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we have a 2+ node cluster which is replicating from an async master and the binlog_format is set to STATEMENT and multi-row inserts are executed on a table with an auto_increment column such that values are automatically generated by MySQL, then the server node generates wrong auto_increment values, which are different from what was generated on the async master. In the title of the MDEV-9519 it was proposed to ban start slave on a Galera if master binlog_format = statement and wsrep_auto_increment_control = 1, but the problem can be solved without such a restriction. The causes and fixes: 1. We need to improve processing of changing the auto-increment values after changing the cluster size. 2. If wsrep auto_increment_control switched on during operation of the node, then we should immediately update the auto_increment_increment and auto_increment_offset global variables, without waiting of the next invocation of the wsrep_view_handler_cb() callback. In the current version these variables retain its initial values if wsrep_auto_increment_control is switched on during operation of the node, which leads to inconsistent results on the different nodes in some scenarios. 3. If wsrep auto_increment_control switched off during operation of the node, then we must return the original values of the auto_increment_increment and auto_increment_offset global variables, as the user has set. To make this possible, we need to add a "shadow copies" of these variables (which stores the latest values set by the user). https://jira.mariadb.org/browse/MDEV-9519
* | | MDEV-15740 Fix wsrep recovery with wsrep_emulate_bin_logTeemu Ollakka2019-01-271-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the TC log did not provide list of XIDs to recover, the commit by XID was skipped during wsrep recovery if binlog emulation was on. However, with wsrep we want to commit every prepared transaction with assigned wsrep XID since the transaction has already been committed in the cluster. Added a special condition to always proceed to commit by XID in xarecover_handlerton() if binlog is off and the recovered transaction has wsrep XID.
* | | MDEV-15740 Backport wsrep recovery fixes from 10.4.Teemu Ollakka2019-01-251-3/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Clear wsrep XID in innobase_rollback_by_xid() for recovered wsrep transaction in order to avoid resetting XID storage when rolling back wsrep transaction during recovery. Sort wsrep XIDs read from storage engine in ascending order and erify that the range is continuous during crash recovery. If binlog is off, commit all recovered transactions for continuous seqno range. This is safe because all transactions with wsrep XID have been certified and must be committed in the cluster. On the other hand if binlog is on, respect binlog as a transaction coordinator in order to avoid missing transactions in binlog that have been committed into storage engine .
* | | Merge branch '10.1' into 10.2Oleksandr Byelkin2018-09-141-1/+3
|\ \ \ | |/ /
| * | Merge branch '10.0-galera' into 10.1Sergei Golubchik2018-09-071-0/+1
| |\ \
| | * | MDEV-16799: Test wsrep.variables crash at sql_class.cc:639 thd_get_ha_dataJan Lindström2018-07-241-0/+1
| | | | | | | | | | | | | | | | | | | | Problem was that binlog_hton was not initialized fully when needed i.e. when wsrep_on = true.
| * | | compiler warnings (clang 4.0.1 on i386)Sergei Golubchik2018-09-041-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | extra/mariabackup/fil_cur.cc:361:42: warning: format specifies type 'unsigned long' but the argument has type 'ib_int64_t' (aka 'long long') [-Wformat] extra/mariabackup/fil_cur.cc:376:9: warning: format specifies type 'unsigned long' but the argument has type 'ib_int64_t' (aka 'long long') [-Wformat] sql/handler.cc:6196:45: warning: format specifies type 'unsigned long' but the argument has type 'wsrep_trx_id_t' (aka 'unsigned long long') [-Wformat] sql/log.cc:1681:16: warning: format specifies type 'unsigned long' but the argument has type 'size_t' (aka 'unsigned int') [-Wformat] sql/log.cc:1687:16: warning: format specifies type 'unsigned long' but the argument has type 'size_t' (aka 'unsigned int') [-Wformat] sql/wsrep_sst.cc:1388:86: warning: format specifies type 'long' but the argument has type 'wsrep_seqno_t' (aka 'long long') [-Wformat] sql/wsrep_sst.cc:232:86: warning: format specifies type 'long' but the argument has type 'wsrep_seqno_t' (aka 'long long') [-Wformat] storage/connect/filamdbf.cpp:450:47: warning: format specifies type 'short' but the argument has type 'int' [-Wformat] storage/connect/filamdbf.cpp:970:47: warning: format specifies type 'short' but the argument has type 'int' [-Wformat] storage/connect/inihandl.cpp:197:16: warning: address of array 'key->name' will always evaluate to 'true' [-Wpointer-bool-conversion] storage/innobase/btr/btr0scrub.cc:151:17: warning: format specifies type 'long' but the argument has type 'int' [-Wformat] storage/innobase/buf/buf0buf.cc:5085:8: warning: nonnull parameter 'bpage' will evaluate to 'true' on first encounter [-Wpointer-bool-conversion] storage/innobase/fil/fil0crypt.cc:2454:5: warning: format specifies type 'long' but the argument has type 'int' [-Wformat] storage/innobase/handler/ha_innodb.cc:18685:7: warning: format specifies type 'unsigned long' but the argument has type 'wsrep_trx_id_t' (aka 'unsigned long long') [-Wformat] storage/innobase/row/row0mysql.cc:3319:5: warning: format specifies type 'long' but the argument has type 'int' [-Wformat] storage/innobase/row/row0mysql.cc:3327:5: warning: format specifies type 'long' but the argument has type 'int' [-Wformat] storage/maria/ma_norec.c:35:10: warning: implicit conversion from 'int' to 'my_bool' (aka 'char') changes value from 131 to -125 [-Wconstant-conversion] storage/maria/ma_norec.c:42:10: warning: implicit conversion from 'int' to 'my_bool' (aka 'char') changes value from 131 to -125 [-Wconstant-conversion] storage/maria/ma_test2.c:1009:12: warning: format specifies type 'unsigned long' but the argument has type 'size_t' (aka 'unsigned int') [-Wformat] storage/maria/ma_test2.c:1010:12: warning: format specifies type 'unsigned long' but the argument has type 'size_t' (aka 'unsigned int') [-Wformat] storage/mroonga/ha_mroonga.cpp:9189:44: warning: use of logical '&&' with constant operand [-Wconstant-logical-operand] storage/mroonga/vendor/groonga/lib/expr.c:4987:22: warning: comparison of constant -1 with expression of type 'grn_operator' is always false [-Wtautological-constant-out-of-range-compare] storage/xtradb/btr/btr0scrub.cc:151:17: warning: format specifies type 'long' but the argument has type 'int' [-Wformat] storage/xtradb/buf/buf0buf.cc:5047:8: warning: nonnull parameter 'bpage' will evaluate to 'true' on first encounter [-Wpointer-bool-conversion] storage/xtradb/fil/fil0crypt.cc:2454:5: warning: format specifies type 'long' but the argument has type 'int' [-Wformat] storage/xtradb/row/row0mysql.cc:3324:5: warning: format specifies type 'long' but the argument has type 'int' [-Wformat] storage/xtradb/row/row0mysql.cc:3332:5: warning: format specifies type 'long' but the argument has type 'int' [-Wformat] unittest/sql/mf_iocache-t.cc:120:35: warning: format specifies type 'unsigned long' but the argument has type 'int' [-Wformat] unittest/sql/mf_iocache-t.cc:96:35: note: expanded from macro 'INFO_TAIL'
* | | | Merge 10.1 into 10.2Marko Mäkelä2018-08-311-28/+3
|\ \ \ \ | |/ / /
| * | | Revert MDEV-9519 due to regressionsMarko Mäkelä2018-08-311-28/+3
| | | | | | | | | | | | | | | | This reverts commit 75dfd4acb995789ca5f86ccbd361fff9d2797e79.
* | | | Merge 10.1 into 10.2Marko Mäkelä2018-08-211-3/+28
|\ \ \ \ | |/ / /
| * | | This is patch for the https://jira.mariadb.org/browse/MDEV-9519 issue:Julius Goryavsky2018-08-151-3/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we have a 2+ node cluster which is replicating from an async master and the binlog_format is set to STATEMENT and multi-row inserts are executed on a table with an auto_increment column such that values are automatically generated by MySQL, then the server node generates wrong auto_increment values, which are different from what was generated on the async master. The causes and fixes: 1. We need to improve processing of changing the auto-increment values after changing the cluster size. 2. If wsrep auto_increment_control switched on during operation of the node, then we should immediately update the auto_increment_increment and auto_increment_offset global variables, without waiting of the next invocation of the wsrep_view_handler_cb() callback. In the current version these variables retain its initial values if wsrep_auto_increment_control is switched on during operation of the node, which leads to inconsistent results on the different nodes in some scenarios. 3. If wsrep auto_increment_control switched off during operation of the node, then we must return the original values of the auto_increment_increment and auto_increment_offset global variables, as the user has set. To make this possible, we need to add a "shadow copies" of these variables (which stores the latest values set by the user).
* | | | Merge branch '10.1' into 10.2Sergei Golubchik2018-06-281-2/+2
|\ \ \ \ | |/ / /
| * | | MDEV-16615 ASAN SEGV in handler::print_error or server crash after error ↵Sergei Golubchik2018-06-281-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | upon CREATE TABLE table->in_use is not always set and a KILL signal can arrive anytime.
* | | | Merge branch '10.1' into 10.2Sergei Golubchik2018-06-211-1/+8
|\ \ \ \ | |/ / /
| * | | MDEV-13577 slave_parallel_mode=optimistic should not report the mode's ↵Sergei Golubchik2018-06-201-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | specific temporary errors Revert 7bbe324fc17 Fix the bug differently (in log_event.cc) Fix the test case to actually fail without the bug fix
| * | | Merge branch '10.0-galera' into 10.1Vicențiu Ciorbaru2018-06-121-0/+7
| |\ \ \ | | |/ /
| | * | Merge tag 'mariadb-10.0.35' into 10.0-galeraJan Lindström2018-05-071-15/+4
| | |\ \
| | * \ \ Merge remote-tracking branch 'origin/5.5-galera' into 10.0-galeraJan Lindström2018-05-071-0/+6
| | |\ \ \
| | | * \ \ Merge tag 'mariadb-5.5.60' into 5.5-galeraJan Lindström2018-04-241-1/+2
| | | |\ \ \ | | | | | |/ | | | | |/|
| | | * | | MW-322 - CTAS fix merged to 5.5-v25 branchsjaakola2017-07-201-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Jan Lindström <jan.lindstrom@mariadb.com>
| | | * | | Merge tag 'mariadb-5.5.56' into 5.5-galeraSachin Setiya2017-05-031-1/+1
| | | |\ \ \
| | | * \ \ \ Merge tag 'mariadb-5.5.55' into bb-5.5-sachin-mergeSachin Setiya2017-04-181-3/+2
| | | |\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Sachin Setiya <sachin.setiya@mariadb.com>
| | | * \ \ \ \ Merge tag 'mariadb-5.5.54' into 5.5-galeramariadb-galera-5.5.54Nirbhay Choubey2016-12-271-1/+1
| | | |\ \ \ \ \
| | | * \ \ \ \ \ Merge tag 'mariadb-5.5.51' into 5.5-galeraNirbhay Choubey2016-08-101-1/+2
| | | |\ \ \ \ \ \
| | | * \ \ \ \ \ \ Merge tag 'mariadb-5.5.49' into 5.5-galeraNirbhay Choubey2016-04-251-2/+2
| | | |\ \ \ \ \ \ \
| | | * \ \ \ \ \ \ \ Merge branch '5.5' into 5.5-galeraNirbhay Choubey2015-02-181-3/+1
| | | |\ \ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Merge banch 5.5 till revision : fdd6c11 - MDEV-7419 Function cli_safe_read not exported Conflicts: .bzrignore debian/dist/Debian/mariadb-galera-server-5.5.files.in debian/dist/Ubuntu/mariadb-galera-server-5.5.files.in storage/tokudb/CMakeLists.txt support-files/build-tags
| | | * \ \ \ \ \ \ \ \ bzr merge -rtag:mariadb-5.5.40 maria/5.5Nirbhay Choubey2014-10-091-8/+3
| | | |\ \ \ \ \ \ \ \ \
View Lorry Controller Status