mirror/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2025-01-28 17:54:16 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
mariadb/include/wsrep.h

87 lines
3.7 KiB
C
Raw Normal View History

MDEV-6247: Merge 10.0-galera to 10.1. Merged lp:maria/maria-10.0-galera up to revision 3879. Added a new functions to handler API to forcefully abort_transaction, producing fake_trx_id, get_checkpoint and set_checkpoint for XA. These were added for future possiblity to add more storage engines that could use galera replication.
2014-08-06 15:39:15 +03:00
/* Copyright 2014 Codership Oy <http://www.codership.com> & SkySQL Ab
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; version 2 of the License.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Merge branch '5.5' into 10.1
2019-05-11 22:19:05 +03:00
Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1335 USA */
MDEV-6247: Merge 10.0-galera to 10.1. Merged lp:maria/maria-10.0-galera up to revision 3879. Added a new functions to handler API to forcefully abort_transaction, producing fake_trx_id, get_checkpoint and set_checkpoint for XA. These were added for future possiblity to add more storage engines that could use galera replication.
2014-08-06 15:39:15 +03:00
#ifndef WSREP_INCLUDED
cleanup: galera merge, simple changes
2014-09-25 23:00:45 +02:00
#define WSREP_INCLUDED
MDEV-6247: Merge 10.0-galera to 10.1. Merged lp:maria/maria-10.0-galera up to revision 3879. Added a new functions to handler API to forcefully abort_transaction, producing fake_trx_id, get_checkpoint and set_checkpoint for XA. These were added for future possiblity to add more storage engines that could use galera replication.
2014-08-06 15:39:15 +03:00
Galera4
2019-01-23 15:30:00 +04:00
#include <my_config.h>
MDEV-6247: Merge 10.0-galera to 10.1. Merged lp:maria/maria-10.0-galera up to revision 3879. Added a new functions to handler API to forcefully abort_transaction, producing fake_trx_id, get_checkpoint and set_checkpoint for XA. These were added for future possiblity to add more storage engines that could use galera replication.
2014-08-06 15:39:15 +03:00
#ifdef WITH_WSREP
MDEV-20051: Add new mode to wsrep_OSU_method in which Galera checks storage 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.
2019-10-02 13:24:34 +03:00
MDEV-6247: Merge 10.0-galera to 10.1. Merged lp:maria/maria-10.0-galera up to revision 3879. Added a new functions to handler API to forcefully abort_transaction, producing fake_trx_id, get_checkpoint and set_checkpoint for XA. These were added for future possiblity to add more storage engines that could use galera replication.
2014-08-06 15:39:15 +03:00
#define IF_WSREP(A,B) A
MDEV-20051: Add new mode to wsrep_OSU_method in which Galera checks storage 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.
2019-10-02 13:24:34 +03:00
MDEV-6247: Merge 10.0-galera to 10.1. Merged lp:maria/maria-10.0-galera up to revision 3879. Added a new functions to handler API to forcefully abort_transaction, producing fake_trx_id, get_checkpoint and set_checkpoint for XA. These were added for future possiblity to add more storage engines that could use galera replication.
2014-08-06 15:39:15 +03:00
#define DBUG_ASSERT_IF_WSREP(A) DBUG_ASSERT(A)
#define WSREP_MYSQL_DB (char *)"mysql"
MDEV-24119 MDL BF-BF Conflict caused by TRUNCATE TABLE This PR fixes same issue as MDEV-21577 for TRUNCATE TABLE. MDEV-21577 fixed TOI replication for OPTIMIZE, REPAIR and ALTER TABLE operating on FK child table. It was later found out that also TRUNCATE has similar problem and needs a fix. The actual fix is to do FK parent table lookup before TRUNCATE TOI isolation and append found FK parent table names in certification key list for the write set. PR contains also new test scenario in galera_ddl_fk_conflict test where FK child has two FK parent tables and there are two DML transactions operating on both parent tables. For development convenience, new TO isolation macro was added: WSREP_TO_ISOLATION_BEGIN_IF and WSREP_TO_ISOLATION_BEGIN_ALTER macro was changed to skip the goto statement. Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
2020-11-04 13:42:18 +02:00
#define WSREP_TO_ISOLATION_BEGIN_IF(db_, table_, table_list_) \
if (WSREP_ON && WSREP(thd) && wsrep_to_isolation_begin(thd, db_, table_, table_list_))
MDEV-20051: Add new mode to wsrep_OSU_method in which Galera checks storage 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.
2019-10-02 13:24:34 +03:00
MDEV-24119 MDL BF-BF Conflict caused by TRUNCATE TABLE This PR fixes same issue as MDEV-21577 for TRUNCATE TABLE. MDEV-21577 fixed TOI replication for OPTIMIZE, REPAIR and ALTER TABLE operating on FK child table. It was later found out that also TRUNCATE has similar problem and needs a fix. The actual fix is to do FK parent table lookup before TRUNCATE TOI isolation and append found FK parent table names in certification key list for the write set. PR contains also new test scenario in galera_ddl_fk_conflict test where FK child has two FK parent tables and there are two DML transactions operating on both parent tables. For development convenience, new TO isolation macro was added: WSREP_TO_ISOLATION_BEGIN_IF and WSREP_TO_ISOLATION_BEGIN_ALTER macro was changed to skip the goto statement. Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
2020-11-04 13:42:18 +02:00
#define WSREP_TO_ISOLATION_BEGIN(db_, table_, table_list_) \
MDEV-6247: Merge 10.0-galera to 10.1. Merged lp:maria/maria-10.0-galera up to revision 3879. Added a new functions to handler API to forcefully abort_transaction, producing fake_trx_id, get_checkpoint and set_checkpoint for XA. These were added for future possiblity to add more storage engines that could use galera replication.
2014-08-06 15:39:15 +03:00
if (WSREP_ON && WSREP(thd) && wsrep_to_isolation_begin(thd, db_, table_, table_list_)) \
MDEV-20051: Add new mode to wsrep_OSU_method in which Galera checks storage 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.
2019-10-02 13:24:34 +03:00
goto wsrep_error_label;
#define WSREP_TO_ISOLATION_BEGIN_CREATE(db_, table_, table_list_, create_info_) \
Merge 10.4 into 10.5
2020-11-13 21:54:21 +02:00
if (WSREP_ON && WSREP(thd) && \
MDEV-20051: Add new mode to wsrep_OSU_method in which Galera checks storage 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.
2019-10-02 13:24:34 +03:00
wsrep_to_isolation_begin(thd, db_, table_, \
Merge 10.4 into 10.5
2020-11-13 21:54:21 +02:00
table_list_, nullptr, nullptr, create_info_))\
wsrep: create a macro for the error: label that is used by WSREP_TO_ISOLATION_BEGIN and other galera macros, to avoid the need for wrapping this label in #ifdef WITH_WSREP/#endif
2018-09-27 17:28:01 +02:00
goto wsrep_error_label;
MDEV-6247: Merge 10.0-galera to 10.1. Merged lp:maria/maria-10.0-galera up to revision 3879. Added a new functions to handler API to forcefully abort_transaction, producing fake_trx_id, get_checkpoint and set_checkpoint for XA. These were added for future possiblity to add more storage engines that could use galera replication.
2014-08-06 15:39:15 +03:00
Merge 10.4 into 10.5
2020-11-13 21:54:21 +02:00
#define WSREP_TO_ISOLATION_BEGIN_ALTER(db_, table_, table_list_, alter_info_, fk_tables_, create_info_) \
if (WSREP(thd) && wsrep_thd_is_local(thd) && \
wsrep_to_isolation_begin(thd, db_, table_, \
table_list_, alter_info_, \
fk_tables_, create_info_)) \
wsrep: create a macro for the error: label that is used by WSREP_TO_ISOLATION_BEGIN and other galera macros, to avoid the need for wrapping this label in #ifdef WITH_WSREP/#endif
2018-09-27 17:28:01 +02:00
goto wsrep_error_label;
Merge branch '10.0-galera' into 10.1
2018-09-07 15:25:27 +02:00
Galera4
2019-01-23 15:30:00 +04:00
#define WSREP_TO_ISOLATION_END \
if ((WSREP(thd) && wsrep_thd_is_local_toi(thd)) || \
wsrep_thd_is_in_rsu(thd)) \
MDEV-6247: Merge 10.0-galera to 10.1. Merged lp:maria/maria-10.0-galera up to revision 3879. Added a new functions to handler API to forcefully abort_transaction, producing fake_trx_id, get_checkpoint and set_checkpoint for XA. These were added for future possiblity to add more storage engines that could use galera replication.
2014-08-06 15:39:15 +03:00
wsrep_to_isolation_end(thd);
Merge branch '10.0-galera' into bb-10.1-serg
2016-02-24 01:21:40 -05:00
/*
Checks if lex->no_write_to_binlog is set for statements that use LOCAL or
NO_WRITE_TO_BINLOG.
*/
#define WSREP_TO_ISOLATION_BEGIN_WRTCHK(db_, table_, table_list_) \
if (WSREP(thd) && !thd->lex->no_write_to_binlog \
wsrep: create a macro for the error: label that is used by WSREP_TO_ISOLATION_BEGIN and other galera macros, to avoid the need for wrapping this label in #ifdef WITH_WSREP/#endif
2018-09-27 17:28:01 +02:00
&& wsrep_to_isolation_begin(thd, db_, table_, table_list_)) goto wsrep_error_label;
Merge branch '10.0-galera' into bb-10.1-serg
2016-02-24 01:21:40 -05:00
MDEV-21577 MDL BF-BF conflict 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>
2020-10-27 12:45:42 +02:00
#define WSREP_TO_ISOLATION_BEGIN_FK_TABLES(db_, table_, table_list_, fk_tables) \
if (WSREP(thd) && !thd->lex->no_write_to_binlog \
MDEV-24119 MDL BF-BF Conflict caused by TRUNCATE TABLE This PR fixes same issue as MDEV-21577 for TRUNCATE TABLE. MDEV-21577 fixed TOI replication for OPTIMIZE, REPAIR and ALTER TABLE operating on FK child table. It was later found out that also TRUNCATE has similar problem and needs a fix. The actual fix is to do FK parent table lookup before TRUNCATE TOI isolation and append found FK parent table names in certification key list for the write set. PR contains also new test scenario in galera_ddl_fk_conflict test where FK child has two FK parent tables and there are two DML transactions operating on both parent tables. For development convenience, new TO isolation macro was added: WSREP_TO_ISOLATION_BEGIN_IF and WSREP_TO_ISOLATION_BEGIN_ALTER macro was changed to skip the goto statement. Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
2020-11-04 13:42:18 +02:00
&& wsrep_to_isolation_begin(thd, db_, table_, table_list_, NULL, fk_tables))
MDEV-21577 MDL BF-BF conflict 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>
2020-10-27 12:45:42 +02:00
compilation failure on Windows sql\sql_acl.cc(3114): error C2220: warning treated as error - no 'object' file generated sql\sql_acl.cc(3114): warning C4390: ';': empty controlled statement found; is this the intent?
2018-10-18 19:33:41 +02:00
#define WSREP_SYNC_WAIT(thd_, before_) \
{ if (WSREP_CLIENT(thd_) && \
wsrep: create a macro for the error: label that is used by WSREP_TO_ISOLATION_BEGIN and other galera macros, to avoid the need for wrapping this label in #ifdef WITH_WSREP/#endif
2018-09-27 17:28:01 +02:00
wsrep_sync_wait(thd_, before_)) goto wsrep_error_label; }
Merge remote-tracking branch 'origin/10.0-galera' into 10.1
2017-08-21 13:35:00 +03:00
Galera4
2019-01-23 15:30:00 +04:00
#else /* !WITH_WSREP */
/* These macros are needed to compile MariaDB without WSREP support
* (e.g. embedded) */
MDEV-6247: Merge 10.0-galera to 10.1. Merged lp:maria/maria-10.0-galera up to revision 3879. Added a new functions to handler API to forcefully abort_transaction, producing fake_trx_id, get_checkpoint and set_checkpoint for XA. These were added for future possiblity to add more storage engines that could use galera replication.
2014-08-06 15:39:15 +03:00
#define IF_WSREP(A,B) B
#define WSREP_DEBUG(...)
#define WSREP_ERROR(...)
compilation failure on Windows sql\sql_acl.cc(3114): error C2220: warning treated as error - no 'object' file generated sql\sql_acl.cc(3114): warning C4390: ';': empty controlled statement found; is this the intent?
2018-10-18 19:33:41 +02:00
#define WSREP_TO_ISOLATION_BEGIN(db_, table_, table_list_) do { } while(0)
Merge 10.4 into 10.5
2020-11-13 21:54:21 +02:00
#define WSREP_TO_ISOLATION_BEGIN_ALTER(db_, table_, table_list_, alter_info_, fk_tables_, create_info_)
MDEV-21577 MDL BF-BF conflict 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>
2020-10-27 12:45:42 +02:00
#define WSREP_TO_ISOLATION_BEGIN_FK_TABLES(db_, table_, table_list_, fk_tables_)
MDEV-6247: Merge 10.0-galera to 10.1. Merged lp:maria/maria-10.0-galera up to revision 3879. Added a new functions to handler API to forcefully abort_transaction, producing fake_trx_id, get_checkpoint and set_checkpoint for XA. These were added for future possiblity to add more storage engines that could use galera replication.
2014-08-06 15:39:15 +03:00
#define WSREP_TO_ISOLATION_END
MDEV-20051: Add new mode to wsrep_OSU_method in which Galera checks storage 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.
2019-10-02 13:24:34 +03:00
#define WSREP_TO_ISOLATION_BEGIN_CREATE(db_, table_, table_list_, create_info_)
Merge branch '10.0-galera' into bb-10.1-serg
2016-02-24 01:21:40 -05:00
#define WSREP_TO_ISOLATION_BEGIN_WRTCHK(db_, table_, table_list_)
Merge remote-tracking branch 'origin/10.0-galera' into 10.1
2017-08-21 13:35:00 +03:00
#define WSREP_SYNC_WAIT(thd_, before_)
#endif /* WITH_WSREP */
MDEV-6247: Merge 10.0-galera to 10.1. Merged lp:maria/maria-10.0-galera up to revision 3879. Added a new functions to handler API to forcefully abort_transaction, producing fake_trx_id, get_checkpoint and set_checkpoint for XA. These were added for future possiblity to add more storage engines that could use galera replication.
2014-08-06 15:39:15 +03:00
Merge remote-tracking branch 'origin/10.0-galera' into 10.1
2017-08-21 13:35:00 +03:00
#endif /* WSREP_INCLUDED */
Reference in a new issue Copy permalink