summaryrefslogtreecommitdiff
path: root/include/mysql
Commit message (Collapse)AuthorAgeFilesLines
* Merge 10.2 into 10.3Marko Mäkelä2021-08-312-6/+6
|\
| * Fix GCC 11 -Wmaybe-uninitialized for PLUGIN_PERFSCHEMAMarko Mäkelä2021-08-302-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | init_mutex_v1_t: Stop lying that the mutex parameter is const. GCC 11.2.0 assumes that it is and could complain about any mysql_mutex_t being uninitialized even after mysql_mutex_init() as long as PLUGIN_PERFSCHEMA is enabled. init_rwlock_v1_t, init_cond_v1_t: Remove untruthful const qualifiers. Note: init_socket_v1_t is expecting that the socket fd has already been created before PSI_SOCKET_CALL(init_socket), and therefore that parameter really is being treated as a pointer to const.
* | Merge 10.2 into 10.3Marko Mäkelä2021-03-181-3/+0
|\ \ | |/
| * MDEV-24853: Duplicate key generated during cluster configuration changeJulius Goryavsky2021-03-081-3/+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.
* | galera fixes related to THD::LOCK_thd_killSergei Golubchik2021-02-021-0/+6
| | | | | | | | | | | | Since 2017 (c2118a08b1) THD::awake() no longer requires LOCK_thd_data. It uses LOCK_thd_kill, and this latter mutex is used to prevent a thread of dying, not LOCK_thd_data as before.
* | Merge branch '10.2' into 10.3Oleksandr Byelkin2020-12-231-1/+3
|\ \ | |/
| * document that a fulltext parser plugin can replace mysql_add_word callbackSergei Golubchik2020-12-101-1/+3
| |
* | Merge 10.2 into 10.3Marko Mäkelä2020-09-211-0/+5
|\ \ | |/
| * MDEV-23101 : SIGSEGV in lock_rec_unlock() when Galera is enabledJan Lindström2020-09-101-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove incorrect BF (brute force) handling from lock_rec_has_to_wait_in_queue and move condition to correct callers. Add a function to report BF lock waits and assert if incorrect BF-BF lock wait happens. wsrep_report_bf_lock_wait Add a new function to report BF lock wait. wsrep_assert_no_bf_bf_wait Add a new function to check do we have a BF-BF wait and if we have report this case and assert as it is a bug. lock_rec_has_to_wait Use new wsrep_assert_bf_wait to check BF-BF wait. lock_rec_create_low lock_table_create Use new function to report BF lock waits. lock_rec_insert_by_trx_age lock_grant_and_move_on_page lock_grant_and_move_on_rec Assert that trx is not Galera as VATS is not compatible with Galera. lock_rec_add_to_queue If there is conflicting lock in a queue make sure that transaction is BF. lock_rec_has_to_wait_in_queue Remove incorrect BF handling. If there is conflicting locks in a queue all transactions must wait. lock_rec_dequeue_from_page lock_rec_unlock If there is conflicting lock make sure it is not BF-BF case. lock_rec_queue_validate Add Galera record locking rules comment and use new function to report BF lock waits. All attempts to reproduce the original assertion have been failed. Therefore, there is no test case on this commit.
* | Merge 10.2 into 10.3Marko Mäkelä2020-07-141-8/+16
|\ \ | |/
| * Merge 10.1 into 10.2Marko Mäkelä2020-07-141-8/+16
| |\
| | * MDEV-22173: socket accept - test for failureDaniel Black2020-07-061-8/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | accept might return an error, including SOCKET_EAGAIN/ SOCKET_EINTR. The caller, usually handle_connections_sockets can these however and invalid file descriptor isn't something to call fcntl on. Thanks to Etienne Guesnet (ATOS) for diagnosis, sample patch description and testing.
* | | Merge 10.2 into 10.3Marko Mäkelä2020-05-251-1/+5
|\ \ \ | |/ /
| * | MDEV-22545: my_vsnprintf behaves not as in C standardOleksandr Byelkin2020-05-241-1/+5
| | | | | | | | | | | | Added parameter %T for string which should be visibly truncated.
* | | Merge branch '10.2' into 10.3Oleksandr Byelkin2020-01-2111-36/+112
|\ \ \ | |/ /
| * | Merge branch '10.1' into 10.2Oleksandr Byelkin2020-01-2011-36/+112
| |\ \ | | |/
| | * Merge branch 'merge-perfschema-5.6' into 10.1Oleksandr Byelkin2020-01-1911-36/+112
| | |\
| | | * 5.6.47Oleksandr Byelkin2020-01-1911-36/+112
| | | |
| | | * 5.6.31Sergei Golubchik2016-06-213-22/+22
| | | |
* | | | Merge branch '10.2' into 10.3Oleksandr Byelkin2019-10-311-2/+2
|\ \ \ \ | |/ / /
| * | | MDEV-18562 [ERROR] InnoDB: WSREP: referenced FK check fail: Lock wait indexJan Lindström2019-10-301-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | Lock wait can happen on secondary index when doing FK checks for wsrep. We should just return error to upper layer and applier will retry operation when needed.
* | | | Merge 10.2 into 10.3Marko Mäkelä2019-05-1444-44/+44
|\ \ \ \ | |/ / /
| * | | Merge 10.1 into 10.2Marko Mäkelä2019-05-1344-44/+44
| |\ \ \ | | |/ /
| | * | Merge branch '5.5' into 10.1Vicențiu Ciorbaru2019-05-1131-31/+31
| | |\ \
| | | * | Update FSF AddressVicențiu Ciorbaru2019-05-1113-13/+13
| | | | | | | | | | | | | | | | | | | | * Update wrong zip-code
| | * | | Update FSF addressVicențiu Ciorbaru2019-05-113-3/+3
| | | | |
| | * | | Merge branch '5.5' into 10.1Vicențiu Ciorbaru2019-05-118-8/+8
| | |\ \ \ | | | |/ /
| | | * | Follow-up to changing FSF addressVicențiu Ciorbaru2019-05-115-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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'
| | | * | Update FSF addressMichal Schorm2019-05-103-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This commit is based on the work of Michal Schorm, rebased on the earliest MariaDB version. Th command line used to generate this diff was: find ./ -type f \ -exec sed -i -e 's/Foundation, Inc., 59 Temple Place, Suite 330, Boston, /Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, /g' {} \; \ -exec sed -i -e 's/Foundation, Inc. 59 Temple Place.* Suite 330, Boston, /Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, /g' {} \; \ -exec sed -i -e 's/MA.*.....-1307.*USA/MA 02110-1335 USA/g' {} \; \ -exec sed -i -e 's/Foundation, Inc., 59 Temple/Foundation, Inc., 51 Franklin/g' {} \; \ -exec sed -i -e 's/Place, Suite 330, Boston, MA.*02111-1307.*USA/Street, Fifth Floor, Boston, MA 02110-1335 USA/g' {} \; \ -exec sed -i -e 's/MA.*.....-1307/MA 02110-1335/g' {} \;
* | | | | Merge remote-tracking branch 'origin/10.2' into 10.3bb-10.3-janmergeJan Lindström2019-04-121-1/+1
|\ \ \ \ \ | |/ / / /
| * | | | Fix wsrep_thd_is_applier macro to point correct function name.Jan Lindström2019-04-101-1/+1
| | | | |
* | | | | Merge branch '10.2' into 10.3Sergei Golubchik2019-03-291-12/+14
|\ \ \ \ \ | |/ / / /
| * | | | Merge branch '10.1' into 10.2Sergei Golubchik2019-03-291-12/+14
| |\ \ \ \ | | |/ / /
| | * | | Revert MDEV-18464 and MDEV-12009Marko Mäkelä2019-03-281-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 21b2fada7ab7f35c898c02d2f918461409cc9c8e and commit 81d71ee6b21870772c336bff15b71904914f146a. The MDEV-18464 change introduces a few data race issues. Contrary to the documentation, the field trx_t::victim is not always being protected by lock_sys_t::mutex and trx_t::mutex. Most importantly, it seems that KILL QUERY could wrongly avoid acquiring both mutexes when invoking lock_trx_handle_wait_low(), in case another thread had already set trx->victim=true. We also revert MDEV-12009, because it should depend on the MDEV-18464 fix being present.
| | * | | MDEV-12009: Allow to force kill user threads/query which are flagged as high ↵Jan Lindström2019-03-281-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | priority by Galera As noted on kill_one_thread SUPER should be able to kill even system threads i.e. threads/query flagged as high priority or wsrep applier thread. Normal user, should not able to kill threads/query flagged as high priority (BF) or wsrep applier thread.
| | * | | cmake: re-enable -Werror in the maintainer modeSergei Golubchik2019-03-271-12/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | now we can afford it. Fix -Werror errors. Note: * old gcc is bad at detecting uninit variables, disable it. * time_t is int or long, cast it for printf's
| | * | | MDEV-9519: Data corruption will happen on the Galera cluster size changeJulius Goryavsky2019-02-251-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | | | | Merge 10.2 into 10.3Marko Mäkelä2019-03-191-0/+6
|\ \ \ \ \ | |/ / / /
| * | | | MDEV-17262: mysql crashed on galera while node rejoined cluster (#895)sysprg2019-03-181-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch contains a fix for the MDEV-17262/17243 issues and new mtr test. These issues (MDEV-17262/17243) have two reasons: 1) After an intermediate commit, a transaction loses its status of "transaction that registered in the MySQL for 2pc coordinator" (in the InnoDB) due to the fact that since version 10.2 the write_row() function (which located in the ha_innodb.cc) does not call trx_register_for_2pc(m_prebuilt->trx) during the processing of split transactions. It is necessary to restore this call inside the write_row() when an intermediate commit was made (for a split transaction). Similarly, we need to set the flag of the started transaction (m_prebuilt->sql_stat_start) after intermediate commit. The table->file->extra(HA_EXTRA_FAKE_START_STMT) called from the wsrep_load_data_split() function (which located in sql_load.cc) will also do this, but it will be too late. As a result, the call to the wsrep_append_keys() function from the InnoDB engine may be lost or function may be called with invalid transaction identifier. 2) If a transaction with the LOAD DATA statement is divided into logical mini-transactions (of the 10K rows) and binlog is rotated, then in rare cases due to the wsrep handler re-registration at the boundary of the split, the last portion of data may be lost. Since splitting of the LOAD DATA into mini-transactions is technical, I believe that we should not allow these mini-transactions to fall into separate binlogs. Therefore, it is necessary to prohibit the rotation of binlog in the middle of processing LOAD DATA statement. https://jira.mariadb.org/browse/MDEV-17262 and https://jira.mariadb.org/browse/MDEV-17243
* | | | | Merge branch '10.2' into 10.3Sergei Golubchik2019-03-171-1/+3
|\ \ \ \ \ | |/ / / /
| * | | | MDEV-18577: Indexes problem on import dump SQLJan Lindström2019-03-131-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem was that we skipped background persistent statistics calculation on applier nodes if thread is marked as high priority (a.k.a BF). However, on applier nodes all DDL which is replicate will be executed as high priority i.e BF. Fixed by allowing background persistent statistics calculation on applier nodes even when thread is marked as BF. This could lead BF lock waits but for queries on that node needs that statistics.
| * | | | MDEV-9519: Data corruption will happen on the Galera cluster size changeJulius Goryavsky2019-02-261-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* | | | | Merge 10.2 into 10.3Marko Mäkelä2018-11-061-2/+2
|\ \ \ \ \ | |/ / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | main.derived_cond_pushdown: Move all 10.3 tests to the end, trim trailing white space, and add an "End of 10.3 tests" marker. Add --sorted_result to tests where the ordering is not deterministic. main.win_percentile: Add --sorted_result to tests where the ordering is no longer deterministic.
| * | | | Merge 10.1 into 10.2Marko Mäkelä2018-11-061-2/+2
| |\ \ \ \ | | |/ / /
| | * | | Merge 10.0 into 10.1Marko Mäkelä2018-11-051-2/+2
| | |\ \ \
| | | * | | Remove dead code is_thd_killed()Marko Mäkelä2018-11-021-2/+2
| | | | | |
| | * | | | Merge branch '10.0' into 10.1Sergei Golubchik2018-10-301-0/+12
| | |\ \ \ \ | | | |/ / /
| | | * | | MDEV-12547: InnoDB FULLTEXT index has too strict ↵Thirunarayanan Balathandayuthapani2018-10-161-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | innodb_ft_result_cache_limit max limit - Backported the MYSQL_SYSVAR_SIZE_T to 10.0 - The parameter innodb_ft_result_cache_limit was only 32 bits wide also on 64-bit systems. Make it size_t, so that it will be 64 bits on 64-bit systems. - Added a test case that show how innodb_ft_result_cache_limit variables behaves in 32bit and 64 bit system.
* | | | | | Merge 10.2 into 10.3Marko Mäkelä2018-10-091-2/+2
|\ \ \ \ \ \ | |/ / / / /
View Lorry Controller Status