summaryrefslogtreecommitdiff
path: root/sql/wsrep_thd.cc
Commit message (Collapse)AuthorAgeFilesLines
* Merge 10.1 into 10.2Marko Mäkelä2018-08-311-22/+0
|\
| * Revert MDEV-9519 due to regressionsMarko Mäkelä2018-08-311-22/+0
| | | | | | | | This reverts commit 75dfd4acb995789ca5f86ccbd361fff9d2797e79.
* | Merge 10.1 into 10.2Marko Mäkelä2018-08-211-0/+22
|\ \ | |/
| * This is patch for the https://jira.mariadb.org/browse/MDEV-9519 issue:Julius Goryavsky2018-08-151-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-05-101-19/+19
|\ \ | |/
| * MDEV-16005 sporadic failures with galera tests MW-328B and MW-328Csjaakola2018-04-241-19/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These test can sporadically show mutex deadlock warnings between LOCK_wsrep_thd and LOCK_thd_data mutexes. This means that these mutexes can be locked in opposite order by different threads, and thus result in deadlock situation. To fix such issue, the locking policy of these mutexes should be revised and enforced to be uniform. However, a quick code review shows that the number of lock/unlock operations for these mutexes combined is between 100-200, and all these mutex invocations should be checked/fixed. On the other hand, it turns out that LOCK_wsrep_thd is used for protecting access to wsrep variables of THD (wsrep_conflict_state, wsrep_query_state), whereas LOCK_thd_data protects query, db and mysys_var variables in THD. Extending LOCK_thd_data to protect also wsrep variables looks like a viable solution, as there should not be a use case where separate threads need simultaneous access to wsrep variables and THD data variables. In this commit LOCK_wsrep_thd mutex is refactored to be replaced by LOCK_thd_data. By bluntly replacing LOCK_wsrep_thd by LOCK_thd_data, will result in double locking of LOCK_thd_data, and some adjustements have been performed to fix such situations.
* | Merge branch '10.1' into 10.2Sergei Golubchik2017-08-171-1/+1
|\ \ | |/
| * MDEV-13179 main.errors fails with wrong errnoMonty2017-08-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The problem was that the introduction of max-thread-mem-used can cause an allocation error very early, even before mysql_parse() is called. As mysql_parse() calls thd->reset_for_next_command(), which called clear_error(), the error number was lost. Fixed by adding an option to have unique messages for each KILL signal and change max-thread-mem-used to use this new feature. This removes a lot of problems with the original approach, where one could get errors signaled silenty almost any time. ixed by moving clear_error() from reset_for_next_command() to do_command(), before any memory allocation for the thread. Related changes: - reset_for_next_command() now have an optional parameter if we should call clear_error() or not. By default it's called, but not anymore from dispatch_command() which was the original problem. - Added optional paramater to clear_error() to force calling of reset_diagnostics_area(). Before clear_error() only called reset_diagnostics_area() if there was no error, so we normally called reset_diagnostics_area() twice. - This change removed several duplicated calls to clear_error() when starting a query. - Reset max_mem_used on COM_QUIT, to protect against kill during quit. - Use fatal_error() instead of setting is_fatal_error (cleanup) - Set fatal_error if max_thead_mem_used is signaled. (Same logic we use for other places where we are out of resources)
* | Merge 10.1 into 10.2Marko Mäkelä2017-05-221-1/+2
|\ \ | |/
| * Silence bogus GCC 7 warnings -Wimplicit-fallthroughMarko Mäkelä2017-05-171-1/+2
| | | | | | | | | | | | | | | | Do not silence uncertain cases, or fix any bugs. The only functional change should be that ha_federated::extra() is not calling DBUG_PRINT to report an unhandled case for HA_EXTRA_PREPARE_FOR_DROP.
* | Merge 10.1 into 10.2Marko Mäkelä2017-04-281-1/+32
|\ \ | |/
| * MW-329 Fix incorrect affected rows count after replaySachin Setiya2017-04-061-1/+32
| | | | | | | | | | Fixes wsrep_replay_transaction so that it preserves affected rows, last insert id, and message from diagnostics area.
* | MDEV-9114: Bulk operations (Array binding)Oleksandr Byelkin2016-11-021-1/+2
| | | | | | | | (+ default values)
* | MDEV-7145: Delayed replicationKristian Nielsen2016-10-161-1/+0
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Merge feature into 10.2 from feature branch. Delayed replication adds an option CHANGE MASTER TO master_delay=<seconds> Replication will then delay applying events with that many seconds. This creates a replication slave that reflects the state of the master some time in the past. Feature is ported from MySQL source tree. Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>
| * | MDEV-7145: Delayed replication, fix wsrep build failure.Kristian Nielsen2016-10-141-1/+0
| |/ | | | | | | Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>
* | Merge branch '10.1' into 10.2Sergei Golubchik2016-09-091-0/+14
|\ \ | |/
| * Merge branch '10.0-galera' into bb-10.1-sergNirbhay Choubey2016-08-251-0/+14
| |\
| | * MW-44 Disable general log for applier threadsTeemu Ollakka2016-08-211-0/+3
| | |
| | * Refs MW-255sjaakola2016-08-211-0/+9
| | | | | | | | | | | | | | | | | | - popping PS reprepare observer before BF aborted PS replaying begins dangling observer will cause failure in open_table() ater on - test case for this anomaly
| | * MW-292 Reset timestamp after transaction replayDaniele Sciascia2016-07-251-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Transaction replay causes the THD to re-apply the replication events from execution, using the same path appliers do. While applying the log events, the THD's timestamp is set to the timestamp of the event. Setting the timestamp explicitly causes function NOW() to always the timestamp that was set. To avoid this behavior we reset the timestamp after replaying is done.
* | | MDEV-5535: Cannot reopen temporary tableNirbhay Choubey2016-06-101-6/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | mysqld maintains a list of TABLE objects for all temporary tables created within a session in THD. Here each table is represented by a TABLE object. A query referencing a particular temporary table for more than once, however, failed with ER_CANT_REOPEN_TABLE error because a TABLE_SHARE was allocate together with the TABLE, so temporary tables always had only one TABLE per TABLE_SHARE. This patch lift this restriction by separating TABLE and TABLE_SHARE objects and storing TABLE_SHAREs for temporary tables in a list in THD, and TABLEs in a list within their respective TABLE_SHAREs.
* | | Changed my_thread_id to int64 to fix compilation problem withMonty2016-02-081-17/+21
|/ / | | | | | | | | | | my_atomic_add32_explicit on windows Fixed that server_audit.c also works if one compiles with safemalloc Fixed compiler warnings
* | MDEV-8208 Sporadic SEGFAULT on startupSergei Golubchik2016-01-251-0/+11
| | | | | | | | | | | | | | different fix. remove old ones, wait for THD to be fully initialized before continuing with the server startup process. This reverts commits db2e21b, 13615c5, 3f515a0, 70113ee.
* | cleanup: wsrep helper to create a threadSergei Golubchik2016-01-251-7/+10
| |
* | Merge branch 'github/10.0-galera' into 10.1Sergei Golubchik2015-11-191-2/+10
|\ \ | |/
| * refs codership/mysql-wsrep#202 Added schema info into wsrep messagesPhilip Stoev2015-10-191-2/+4
| | | | | | | | Added schema info to wsrep messages above debug level.
| * Refs codership/mysql-wsrep#132sjaakola2015-09-091-0/+1
| | | | | | | | - fix for THD::m_digest initialization, according to Raghu
| * Refs codership/mysql-wsrep#113 - Extended the protection of local FLUSHsjaakola2015-09-091-0/+5
| | | | | | | | sessions to cover all exclusive MDL locks
| * Merge branch '5.5-galera' into 10.0-galeraNirbhay Choubey2015-06-231-0/+11
| |\
| | * MDEV-8260 : Issues related to concurrent CTASNirbhay Choubey2015-06-191-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | * Wait for aborted thd (victim) to release MDL locks * Skip aborting an already aborted thd * Defer setting OK status in case of CTAS * Minor cosmetic changes * Added a test case
| | * Backport fix for MDEV-7673, MDEV-7203 and MDEV-7192 from 10.0-galeraNirbhay Choubey2015-03-111-0/+10
| | |
| | * bzr merge -r3997..4010 codership-mysql/5.5Nirbhay Choubey2014-08-061-0/+11
| | |
| | * bzr merge -r3985..3997 codership/5.5Nirbhay Choubey2014-06-101-3/+12
| | |
| | * * Merged the missing revision 3934 fromNirbhay Choubey2014-02-051-19/+43
| | | | | | | | | | | | | | | | | | | | | codership-mysql/5.5 (missed in the last merge). * Merged changes from Innodb to xtradb. * Updated WSREP_PATCH_REVNO
| | * Merging revision 3839..3932 from codership-mysql/5.5.Nirbhay Choubey2014-01-091-0/+464
| |
| * refs codership/mysql-wsrep#90 made wsrep_OSU_method session variableTeemu Ollakka2015-05-081-2/+2
| |
| * refs codership/mysql-wsrep#90 - fixed race in OSUTeemu Ollakka2015-05-081-1/+1
| | | | | | | | | | Make sure that thd uses the same method to begin and end OSU operation.
| * MDEV-7192: binlog_annotate_row_events not completely compatible with galeraNirbhay Choubey2015-03-051-3/+8
| | | | | | | | | | | | Annotate_rows event needs to be preserved until the last Rows event has been applied because after it has been applied thd->query points to the query stored inside this event.
* | Merge branch '10.0-galera' into 10.1Nirbhay Choubey2015-07-141-5/+21
| |
* | MDEV-8001 - mysql_reset_thd_for_next_command() takes 0.04% in OLTP ROSergey Vojtovich2015-05-131-1/+1
| | | | | | | | | | | | | | | | Removed mysql_reset_thd_for_next_command(). Call THD::reset_for_next_command() directly instead. mysql_reset_thd_for_next_command() overhead dropped 0.04% -> out of radar. THD::reset_for_next_command() overhead didn't increase.
* | Merge 10.0-galera into 10.1Sergei Golubchik2015-02-061-35/+28
|\ \ | |/
| * MDEV-7123 : MariaDB 10.0.14 Galera node shutdown with signal 11Nirbhay Choubey2015-01-091-5/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | wsrep-patch uses same connection name for constructing Master_info objects. As a result all existing wsrep Master_info objects refer to same rpl_filter object. This could lead to race when multiple threads try to delete/destruct Master_info object, as they would all try to delete the same relay_log object. Fixed by adding a check in Master_info's destructor to not free the "wsrep" rpl_filter, so that its reused by current & subsequent wsrep threads and later reclaimed by free_all_rpl_filters() during server shutdown.
| * MDEV-6740 : Galera crash in rpl_sql_thread_info/cached_charset_compareNirbhay Choubey2014-09-221-28/+9
| | | | | | | | | | | | Properly initialized rpl_sql_thread_info for bf threads. Also removed some dead code.
| * MDEV-6602: rpl.rpl_mdev6020 fails sporadically with SIGABRTJan Lindström2014-08-251-7/+25
| | | | | | | | | | | | | | | | Analysis: Problem is that we execute galera code when we are actually executing asyncronoush replication. Fix: Do not execute galera code if wsrep provider is not set.
| * bzr merge -r4091..4101 codership/5.6/Nirbhay Choubey2014-06-191-0/+23
| |
| * bzr merge -r3985..3991 codership/5.5Nirbhay Choubey2014-05-211-3/+11
| |
| * * bzr merge -r4027..4061 codership/5.6Nirbhay Choubey2014-03-261-2/+0
| | | | | | | | | | * Merged Innodb changes to xtradb
| * bzr merge -r3933..3945 codership/5.5 (Non-InnoDB changes only).Nirbhay Choubey2014-03-251-19/+43
| |
| * merge with MariaDB 5.6 bzr merge lp:maria --rtag:mariadb-10.0.6Seppo Jaakola2013-12-041-9/+76
| | | | | | | | | | | | and a number of fixes to make this buildable. Run also few short multi-master high conflict rate tests, with no issues
| * fixes for wsrep-5.5 mergesSeppo Jaakola2013-11-271-1/+1
| |
View Lorry Controller Status