summaryrefslogtreecommitdiff
path: root/sql/wsrep_mysqld.h
Commit message (Collapse)AuthorAgeFilesLines
* Merge 10.4 into 10.5Marko Mäkelä2021-04-081-3/+4
|\
| * MDEV-25226 Assertion when wsrep_on set OFF with SR transactionDaniele Sciascia2021-04-051-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch makes the following changes around variable wsrep_on: 1) Variable wsrep_on can no longer be updated from a session that has an active transaction running. The original behavior allowed cases like this: BEGIN; INSERT INTO t1 VALUES (1); SET SESSION wsrep_on = OFF; INSERT INTO t1 VALUES (2); COMMIT; With regular transactions this would result in no replication events (not even value 1). With streaming replication it would be unnecessarily complex to achieve the same behavior. In the above example, it would be possible for value 1 to be already replicated if it happened to fill a separate fragment, while value 2 wouldn't. 2) Global variable wsrep_on no longer affects current sessions, only subsequent ones. This is to avoid a similar case to the above, just using just by using global wsrep_on instead session wsrep_on: --connection conn_1 BEGIN; INSERT INTO t1 VALUES(1); --connection conn_2 SET GLOBAL wsrep_on = OFF; --connection conn_1 INSERT INTO t1 VALUES(2); COMMIT; The above example results in the transaction to be replicated, as global wsrep_on will only affect the session wsrep_on of new connections. Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
* | Merge branch '10.4' into 10.5Sergei Golubchik2021-02-231-1/+1
|\ \ | |/
| * Merge branch 'bb-10.4-release' into 10.4Sergei Golubchik2021-02-231-1/+9
| |\
| * | MDEV-24865 : Server crashes when truncate mysql user tablebb-10.4-MDEV-24865Jan Lindström2021-02-161-1/+1
| | | | | | | | | | | | | | | | | | | | | For truncate we try to find out possible foreign key tables using open_tables. However, table_list was not cleaned up properly and there was no error handling. Fixed by cleaning table_list and adding proper error handling.
* | | Merge branch 'bb-10.4-release' into bb-10.5-releaseSergei Golubchik2021-02-151-1/+9
|\ \ \ | | |/ | |/|
| * | updating @@wsrep_cluster_address deadlocksSergei Golubchik2021-02-141-1/+9
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | wsrep_cluster_address_update() causes LOCK_wsrep_slave_threads to be locked under LOCK_wsrep_cluster_config, while normally the order should be the opposite. Fix: don't protect @@wsrep_cluster_address value with the LOCK_wsrep_cluster_config, LOCK_global_system_variables is enough. Only protect wsrep reinitialization with the LOCK_wsrep_cluster_config. And make it use a local copy of the global @@wsrep_cluster_address. Also, introduce a helper function that checks whether wsrep_cluster_address is set and also asserts that it can be safely read by the caller.
* | Merge 10.4 into 10.5Marko Mäkelä2021-01-111-6/+7
|\ \ | |/
| * Update wsrep-lib (new logger interface)Alexey Yurchenko2021-01-071-14/+14
| | | | | | | | | | | | Ensure consistent use of logging macros in wsrep-related code Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
* | MDEV-24546 : AddressSanitizer: initialization-order-fiasco on address ... in ↵Jan Lindström2021-01-091-0/+1
| | | | | | | | | | | | | | | | Sys_var_integer from __static_initialization_and_destruction_0, possibly inside global var wsrep_gtid_server Galera parameter wsrep_gtid_domain_id was defined using a class where actual parameter was not a first member. Fixed this by using normal variable and assigning this value to class member value.
* | Merge 10.4 into 10.5Marko Mäkelä2020-11-131-2/+7
|\ \ | |/
| * MDEV-21577 MDL BF-BF conflictsjaakola2020-11-031-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some DDL statements appear to acquire MDL locks for a table referenced by foreign key constraint from the actual affected table of the DDL statement. OPTIMIZE, REPAIR and ALTER TABLE belong to this class of DDL statements. Earlier MariaDB version did not take this in consideration, and appended only affected table in the certification key list in write set. Because of missing certification information, it could happen that e.g. OPTIMIZE table for FK child table could be allowed to apply in parallel with DML operating on the foreign key parent table, and this could lead to unhandled MDL lock conflicts between two high priority appliers (BF). The fix in this patch, changes the TOI replication for OPTIMIZE, REPAIR and ALTER TABLE statements so that before the execution of respective DDL statement, there is foreign key parent search round. This FK parent search contains following steps: * open and lock the affected table (with permissive shared locks) * iterate over foreign key contstraints and collect and array of Fk parent table names * close all tables open for the THD and release MDL locks * do the actual TOI replication with the affected table and FK parent table names as key values The patch contains also new mtr test for verifying that the above mentioned DDL statements replicate without problems when operating on FK child table. The mtr test scenario #1, which can be used to check if some other DDL (on top of OPTIMIZE, REPAIR and ALTER) could cause similar excessive FK parent table locking. Reviewed-by: Aleksey Midenkov <aleksey.midenkov@mariadb.com> Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
* | Merge 10.4 to 10.5Marko Mäkelä2020-10-221-1/+2
|\ \ | |/
| * Merge 10.3 into 10.4Marko Mäkelä2020-10-221-1/+2
| |\
| | * Merge 10.2 into 10.3Marko Mäkelä2020-10-221-2/+2
| | |\
| | | * MDEV-23894 UBSAN: several call to function show_binlog_vars(THD*, ↵Eugene Kosov2020-10-061-2/+2
| | | | | | | | | | | | | | | | st_mysql_show_var*, char*) through pointer to incorrect function type 'int (*)(THD *, st_mysql_show_var *, void *, system_status_var *, enum_var_type) errors
| | * | Merge 10.2 into 10.3Marko Mäkelä2020-04-271-7/+1
| | |\ \ | | | |/
| | | * Merge 10.1 into 10.2Marko Mäkelä2020-04-271-7/+1
| | | |\
| | | | * MDEV-22203: WSREP_ON is unnecessarily expensive to evaluateMarko Mäkelä2020-04-271-7/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a backport of the applicable part of commit 93475aff8de80a0ef53cbee924bcb70de6e86f2c and commit 2c39f69d34e64a5cf94720e82e78c0ee91bd4649 from 10.4. Before 10.4 and Galera 4, WSREP_ON is a macro that points to a global Boolean variable, so it is not that expensive to evaluate, but we will add an unlikely() hint around it. WSREP_ON_NEW: Remove. This macro was introduced in commit c863159c320008676aff978a7cdde5732678f975 when reverting WSREP_ON to its previous definition. We replace some use of WSREP_ON with WSREP(thd), like it was done in 93475aff8de80a0ef53cbee924bcb70de6e86f2c. Note: the macro WSREP() in 10.1 is equivalent to WSREP_NNULL() in 10.4. Item_func_rand::seed_random(): Avoid invoking current_thd when WSREP is not enabled.
| | | * | Merge 10.1 into 10.2Marko Mäkelä2020-04-221-7/+2
| | | |\ \ | | | | |/
| | | | * MDEV-22271 Excessive stack memory usage due to WSREP_LOGMarko Mäkelä2020-04-171-7/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Several tests that involve stored procedures fail on 10.4 kvm-asan (clang 10) due to stack overrun. The main contributor to this stack overrun is mysql_execute_command(), which is invoked recursively during stored procedure execution. Rebuilding with cmake -DWITH_WSREP=OFF shrunk the stack frame size of mysql_execute_command() by more than 10 kilobytes in a WITH_ASAN=ON, CMAKE_BUILD_TYPE=Debug build. The culprit turned out to be the macro WSREP_LOG, which is allocating a separate 1KiB buffer for every occurrence. We replace the macro with a function, so that the stack will be allocated only when the function is actually invoked. In this way, no stack space will be wasted by default (when WSREP and Galera are disabled). This backports commit b6c5657ef27de034439b1505a8b4815c263d6455 from MariaDB 10.3.1. Without ASAN, compilers can be smarter and optimize the stack usage. The original commit message mentions that 1KiB was saved on GCC 5.4, and 4KiB on Mac OS X Lion, which presumably uses a clang-based compiler.
* | | | | cleanup, less #ifdef'sSergei Golubchik2020-07-041-0/+1
| | | | |
* | | | | MDEV-19749 MDL scalability regression after backup locksEugene Kosov2020-06-231-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | use ilist instread of I_P_List because it's generally slightly faster on inserting, removing and iterating
* | | | | Performance improvements to test if WSREP if activeMonty2020-05-231-0/+1
| | | | |
* | | | | Merge 10.4 into 10.5Marko Mäkelä2020-04-251-14/+8
|\ \ \ \ \ | |/ / / / | | | | | | | | | | | | | | | The functional changes of commit 5836191c8f0658d5d75484766fdcc3d838b0a5c1 (MDEV-21168) are omitted due to MDEV-742 having addressed the issue.
| * | | | MDEV-22203: WSREP_ON is unnecessarily expensive WITH_WSREP=OFFMarko Mäkelä2020-04-241-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the server is compiled WITH_WSREP=OFF, we should avoid evaluating conditions on a global variable that is constant. WSREP_ON_: Renamed from WSREP_ON. Defined only WITH_WSREP=ON. WSREP_ON: Defined as unlikely(WSREP_ON_). wsrep_on(): Defined as WSREP_ON && wsrep_service->wsrep_on_func(). The reason why we have wsrep_on() at all is that the macro WSREP(thd) depends on the definition of THD, and that is intentionally an opaque data type for InnoDB. So, we cannot avoid invoking wsrep_on(), but we can evaluate the less expensive condition WSREP_ON before calling the function.
| * | | | MDEV-22203: WSREP_ON is unnecessarily expensive to evaluateJan Lindström2020-04-241-7/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Replaced WSREP_ON macro by single global variable WSREP_ON that is then updated at server statup and on wsrep_on and wsrep_provider update functions.
| * | | | MDEV-22271 Excessive stack memory usage due to WSREP_LOGTeemu Ollakka2020-04-171-7/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Made WSREP_LOG a function and moved the body out of header. - Reduced the stack allocated buffer size and implemented reprint into dynamically allocated buffer if stack buffer is not large enough to hold the message.
* | | | | Clean up and speed up interfaces for binary row loggingMonty2020-03-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | MDEV-21605 Clean up and speed up interfaces for binary row logging MDEV-21617 Bug fix for previous version of this code The intention is to have as few 'if' as possible in ha_write() and related functions. This is done by pre-calculating once per statement the row_logging state for all tables. Benefits are simpler and faster code both when binary logging is disabled and when it's enabled. Changes: - Added handler->row_logging to make it easy to check it table should be row logged. This also made it easier to disabling row logging for system, internal and temporary tables. - The tables row_logging capabilities are checked once per "statements that updates tables" in THD::binlog_prepare_for_row_logging() which is called when needed from THD::decide_logging_format(). - Removed most usage of tmp_disable_binlog(), reenable_binlog() and temporary saving and setting of thd->variables.option_bits. - Moved checks that can't change during a statement from check_table_binlog_row_based() to check_table_binlog_row_based_internal() - Removed flag row_already_logged (used by sequence engine) - Moved binlog_log_row() to a handler:: - Moved write_locked_table_maps() to THD::binlog_write_table_maps() as most other related binlog functions are in THD. - Removed binlog_write_table_map() and binlog_log_row_internal() as they are now obsolete as 'has_transactions()' is pre-calculated in prepare_for_row_logging(). - Remove 'is_transactional' argument from binlog_write_table_map() as this can now be read from handler. - Changed order of 'if's in handler::external_lock() and wsrep_mysqld.h to first evaluate fast and likely cases before more complex ones. - Added error checking in ha_write_row() and related functions if binlog_log_row() failed. - Don't clear check_table_binlog_row_based_result in clear_cached_table_binlog_row_based_flag() as it's not needed. - THD::clear_binlog_table_maps() has been replaced with THD::reset_binlog_for_next_statement() - Added 'MYSQL_OPEN_IGNORE_LOGGING_FORMAT' flag to open_and_lock_tables() to avoid calculating of binary log format for internal opens. This flag is also used to avoid reading statistics tables for internal tables. - Added OPTION_BINLOG_LOG_OFF as a simple way to turn of binlog temporary for create (instead of using THD::sql_log_bin_off. - Removed flag THD::sql_log_bin_off (not needed anymore) - Speed up THD::decide_logging_format() by remembering if blackhole engine is used and avoid a loop over all tables if it's not used (the common case). - THD::decide_logging_format() is not called anymore if no tables are used for the statement. This will speed up pure stored procedure code with about 5%+ according to some simple tests. - We now get annotated events on slave if a CREATE ... SELECT statement is transformed on the slave from statement to row logging. - In the original code, the master could come into a state where row logging is enforced for all future events if statement could be used. This is now partly fixed. Other changes: - Ensure that all tables used by a statement has query_id set. - Had to restore the row_logging flag for not used tables in THD::binlog_write_table_maps (not normal scenario) - Removed injector::transaction::use_table(server_id_type sid, table tbl) as it's not used. - Cleaned up set_slave_thread_options() - Some more DBUG_ENTER/DBUG_RETURN, code comments and minor indentation changes. - Ensure we only call THD::decide_logging_format_low() once in mysql_insert() (inefficiency). - Don't annotate INSERT DELAYED - Removed zeroing pos_in_table_list in THD::open_temporary_table() as it's already 0
* | | | | Merge 10.4 into 10.5Marko Mäkelä2020-03-211-5/+0
|\ \ \ \ \ | |/ / / /
| * | | | MDEV-21675: Data inconsistency after multirow insert rollback (#1474)Daniele Sciascia2020-03-211-5/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * Remove dead code * MDEV-21675 Data inconsistency after multirow insert rollback This patch fixes data inconsistencies that happen after rollback of multirow inserts, with binlog disabled. For example, statements such as `INSERT INTO t1 VALUES (1,'a'),(1,'b')` that fail with duplicate key error. In such cases the whole statement is rolled back. However, with wsrep_emulate_binlog in effect, the IO_CACHE would not be truncated, and the pending rows events would be replicated to the rest of the cluster. In the above example, it would result in row (1,'a') being replicated, whereas locally the statement is rolled back entirely. Making the cluster inconsistent. The patch changes the code so that prior to statement rollback, pending rows event are removed and the stmt cache reset. That patch also introduces MTR tests that excercise multirow insert statements for regular, and streaming replication.
* | | | | MDEV-20051: Add new mode to wsrep_OSU_method in which Galera checks storage ↵Jan Lindström2020-02-111-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | engine of the effected table Introduced a new wsrep_strict_ddl configuration variable in which Galera checks storage engine of the effected table. If table is not InnoDB (only storage engine currently fully supporting Galera replication) DDL-statement will return error code: ER_GALERA_REPLICATION_NOT_SUPPORTED eng "DDL-statement is forbidden as table storage engine does not support Galera replication" However, when wsrep_replicate_myisam=ON we allow DDL-statements to MyISAM tables. If effected table is allowed storage engine Galera will run normal TOI. This new setting should be for now set globally on all nodes in a cluster. When this setting is set following DDL-clauses accessing tables not supporting Galera replication are refused: * CREATE TABLE (e.g. CREATE TABLE t1(a int) engine=Aria * ALTER TABLE * TRUNCATE TABLE * CREATE VIEW * CREATE TRIGGER * CREATE INDEX * DROP INDEX * RENAME TABLE * DROP TABLE Statements on PROCEDURE, EVENT, FUNCTION are allowed as effected tables are known only at execution. Furthermore, USER, ROLE, SERVER, DATABASE statements are also allowed as they do not really have effected table.
* | | | | Incorrect behaviour of WSREP_SYNC_WAIT_UPTO_GTID (#1442)mkaruza2020-02-051-22/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Function `signal_waiters` assigned `m_committed_seqno` variable outside of mutex lock which caused incorrect behavior of WSREP_SYNC_WAIT_UPTO_GTID. Fixed by moving assignment inside lock. Added handling of OOM and now error is reported. Remove hard-coded seqno value and read seqno directly from current node state.
* | | | | Galera GTID supportmkaruza2020-01-291-5/+120
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Support for galera GTID consistency thru cluster. All nodes in cluster should have same GTID for replicated events which are originating from cluster. Cluster originating commands need to contain sequential WSREP GTID seqno Ignore manual setting of gtid_seq_no=X. In master-slave scenario where master is non galera node replicated GTID is replicated and is preserved in all nodes. To have this - domain_id, server_id and seqnos should be same on all nodes. Node which bootstraps the cluster, to achieve this, sends domain_id and server_id to other nodes and this combination is used to write GTID for events that are replicated inside cluster. Cluster nodes that are executing non replicated events are going to have different GTID than replicated ones, difference will be visible in domain part of gtid. With wsrep_gtid_domain_id you can set domain_id for WSREP cluster. Functions WSREP_LAST_WRITTEN_GTID, WSREP_LAST_SEEN_GTID and WSREP_SYNC_WAIT_UPTO_GTID now works with "native" GTID format. Fixed galera tests to reflect this chances. Add variable to manually update WSREP GTID seqno in cluster Add variable to manipulate and change WSREP GTID seqno. Next command originating from cluster and on same thread will have set seqno and cluster should change their internal counter to it's value. Behavior is same as using @@gtid_seq_no for non WSREP transaction.
* | | | | Merge 10.4 into 10.5Marko Mäkelä2020-01-281-0/+9
|\ \ \ \ \ | |/ / / /
| * | | | MDEV-17571 : Make systemd timeout behavior more compatible with long Galera SSTsJan Lindström2020-01-221-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is 10.4 version. Idea is to create monitor thread for both donor and joiner that will periodically if needed extend systemd timeout while SST is being processed. In 10.4 actual SST is executed by running SST script and exchanging messages on pipe using blocking fgets. This fix starts monitoring thread before SST script is started and we stop monitoring thread when SST has been completed.
* | | | | Merge 10.4 into 10.5Marko Mäkelä2019-09-061-8/+7
|\ \ \ \ \ | |/ / / /
| * | | | MDEV-20378: Galera uses uninitialized memoryJan Lindström2019-08-201-8/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem was that wsrep thread argument was deleted on wrong place. Furthermore, scan method incorrectly used unsafe c_ptr(). Finally, fixed wsrep thread initialization to correctly set up thread_id and pass correct argument to functions and fix signess problem causing compiler errors.
* | | | | Decrease stack space usage of mysql_execute_command()Sergei Golubchik2019-08-231-8/+8
|/ / / / | | | | | | | | | | | | | | | | | | | | - WSREP_DEBUG called WSREP_LOG which allocated a 1K variable on stack for each macro usage (at least gcc can't reuse the stack space). Move this concatenation to happen compile-time, not run-time.
* | | | Merge 10.3 into 10.4Marko Mäkelä2019-08-141-0/+7
|\ \ \ \ | |/ / /
| * | | Merge 10.2 to 10.3Marko Mäkelä2019-08-131-0/+7
| |\ \ \ | | |/ /
| | * | MDEV-20324: Galera threads are not registered to performance schemaJan Lindström2019-08-131-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Galera threads were not registered to performance schema and used pthread_create when mysql_thread_create should have been used. Added test case to verify current galera performance schema instrumentation does work.
* | | | Merge 10.3 into 10.4Marko Mäkelä2019-07-251-3/+15
|\ \ \ \ | |/ / /
| * | | Merge 10.2 into 10.3Eugene Kosov2019-07-161-0/+17
| |\ \ \ | | |/ /
| | * | MDEV-19746: Galera test failures because of wsrep_slave_threads identificationJan Lindström2019-07-151-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Problem was that tests select INFORMATION_SCHEMA.PROCESSLIST processes from user system user and empty state. Thus, there is not clear state for slave threads. Changes: - Added new status variables that store current amount of applier threads (wsrep_applier_thread_count) and rollbacker threads (wsrep_rollbacker_thread_count). This will make clear how many slave threads of certain type there is. - Added THD state "wsrep applier idle" when applier slave thread is waiting for work. This makes finding slave/applier threads easier. - Added force-restart option for mtr to always restart servers between tests to avoid race on start of the test - Added wait_condition_with_debug to wait until the passed statement returns true, or the operation times out. If operation times out, the additional error statement will be executed Changes to be committed: new file: mysql-test/include/force_restart.inc new file: mysql-test/include/wait_condition_with_debug.inc modified: mysql-test/mysql-test-run.pl modified: mysql-test/suite/galera/disabled.def modified: mysql-test/suite/galera/r/MW-336.result modified: mysql-test/suite/galera/r/galera_kill_applier.result modified: mysql-test/suite/galera/r/galera_var_slave_threads.result new file: mysql-test/suite/galera/t/MW-336.cnf modified: mysql-test/suite/galera/t/MW-336.test modified: mysql-test/suite/galera/t/galera_kill_applier.test modified: mysql-test/suite/galera/t/galera_parallel_autoinc_largetrx.test modified: mysql-test/suite/galera/t/galera_parallel_autoinc_manytrx.test modified: mysql-test/suite/galera/t/galera_var_slave_threads.test modified: mysql-test/suite/wsrep/disabled.def modified: mysql-test/suite/wsrep/r/variables.result modified: mysql-test/suite/wsrep/t/variables.test modified: sql/mysqld.cc modified: sql/wsrep_mysqld.cc modified: sql/wsrep_mysqld.h modified: sql/wsrep_thd.cc modified: sql/wsrep_var.cc
* | | | Merge branch '10.3' into 10.4Oleksandr Byelkin2019-05-191-1/+1
|\ \ \ \ | |/ / /
| * | | Merge 10.2 into 10.3Marko Mäkelä2019-05-141-1/+1
| |\ \ \ | | |/ /
| | * | Merge 10.1 into 10.2Marko Mäkelä2019-05-131-1/+1
| | |\ \ | | | |/
| | | * Merge branch '5.5' into 10.1Vicențiu Ciorbaru2019-05-111-1/+1
| | | |
* | | | Fix cmake -DWITH_WSREP=OFFMarko Mäkelä2019-04-031-0/+1
| | | | | | | | | | | | | | | | | | | | Provide a dummy definition of WSREP_NNULL. This was broken in commit b896f60a73aea32843a0a86a35def669d82503af.
View Lorry Controller Status