mariadb

Commit Graph

Author	SHA1	Message	Date
Kristian Nielsen	8ae462a220	MDEV-35019 Provide a way to enable "rollback XA on disconnect" behavior we had before 10.5.2 Implement variable legacy_xa_rollback_at_disconnect to support backwards compatibility for applications that rely on the pre-10.5 behavior for connection disconnect, which is to rollback the transaction (in violation of the XA specification). Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>	1 year ago
Brandon Nesterenko	9808ebe195	MDEV-30978: On slave XA COMMIT/XA ROLLBACK fail to return an error in read-only mode Where a read-only server permits writes through replication, it should not permit user connections to commit/rollback XA transactions prepared via replication. The bug reported in MDEV-30978 shows that this can happen. This is because there is no read only check in the XA transaction logic, the most relevant one occurs in ha_commit_trans() for normal statements/transactions. This patch extends the XA transaction logic to check the read only status of the server before performing an XA COMMIT or ROLLBACK. Reviewed By: Andrei Elkin <andrei.elkin@mariadb.com>	2 years ago
Monty	736ca14323	Don't crash if creating sequence under XA MDEV-22002 Assertion `!is_set() \|\| (m_status == DA_OK_BULK && is_bulk_op())' failed upon CREATE TEMPORARY SEQUENCE under XA	6 years ago
Andrei Elkin	c8ae357341	MDEV-742 XA PREPAREd transaction survive disconnect/server restart Lifted long standing limitation to the XA of rolling it back at the transaction's connection close even if the XA is prepared. Prepared XA-transaction is made to sustain connection close or server restart. The patch consists of - binary logging extension to write prepared XA part of transaction signified with its XID in a new XA_prepare_log_event. The concusion part - with Commit or Rollback decision - is logged separately as Query_log_event. That is in the binlog the XA consists of two separate group of events. That makes the whole XA possibly interweaving in binlog with other XA:s or regular transaction but with no harm to replication and data consistency. Gtid_log_event receives two more flags to identify which of the two XA phases of the transaction it represents. With either flag set also XID info is added to the event. When binlog is ON on the server XID::formatID is constrained to 4 bytes. - engines are made aware of the server policy to keep up user prepared XA:s so they (Innodb, rocksdb) don't roll them back anymore at their disconnect methods. - slave applier is refined to cope with two phase logged XA:s including parallel modes of execution. This patch does not address crash-safe logging of the new events which is being addressed by MDEV-21469. CORNER CASES: read-only, pure myisam, binlog-, @@skip_log_bin, etc Are addressed along the following policies. 1. The read-only at reconnect marks XID to fail for future completion with ER_XA_RBROLLBACK. 2. binlog- filtered XA when it changes engine data is regarded as loggable even when nothing got cached for binlog. An empty XA-prepare group is recorded. Consequent Commit-or-Rollback succeeds in the Engine(s) as well as recorded into binlog. 3. The same applies to the non-transactional engine XA. 4. @@skip_log_bin=OFF does not record anything at XA-prepare (obviously), but the completion event is recorded into binlog to admit inconsistency with slave. The following actions are taken by the patch. At XA-prepare: when empty binlog cache - don't do anything to binlog if RO, otherwise write empty XA_prepare (assert(binlog-filter case)). At Disconnect: when Prepared && RO (=> no binlogging was done) set Xid_cache_element::error := ER_XA_RBROLLBACK keep XID in the cache, and rollback the transaction. At XA-"complete": Discover the error, if any don't binlog the "complete", return the error to the user. Kudos ----- Alexey Botchkov took to drive this work initially. Sergei Golubchik, Sergei Petrunja, Marko Mäkelä provided a number of good recommendations. Sergei Voitovich made a magnificent review and improvements to the code. They all deserve a bunch of thanks for making this work done!	7 years ago
Andrei Elkin	dd3ffdbd92	MDEV-21659 XA rollback foreign_xid is allowed inside active XA MDEV-21854 xa commit `xid` one phase for already prepared transaction must always error out Added state and one-phase option checks to XA "external" commit/rollback branches. While the XA standard does not prohibit it, Commit and Rollback of an XA external to the current ongoing transaction is not allowed; after all the current transaction may rollback to not being able to revert that decision.	6 years ago
Sergey Vojtovich	82e997ad3f	MDEV-21856 - xid_t::formatID has to be constrained to 4 byte size Engine (InnoDB) and XA replication MDEV-742 requires the XID member be of a constant minimum across supported platform ulong size which is 4 bytes.	6 years ago
Sergey Vojtovich	607960c772	MDEV-21766 - Forbid XID with empty 'gtrid' XA specification doesn't permit empty gtrid. It is now enforced by this patch. This solution was agreed in favour of fixing InnoDB, which doesn't expect empty XID since early 10.5. Also fixed wrong assertion (and added a test cases) that didn't permit 64 bytes gtrid + 64 bytes bqual.	6 years ago
Marko Mäkelä	1748a31ae8	MDEV-16675 Unnecessary explicit lock acquisition during UPDATE or DELETE In InnoDB, an INSERT will not create an explicit lock object. Instead, the inserted record is initially implicitly locked by the transaction that wrote its trx_t::id to the hidden system column DB_TRX_ID. (Other transactions would check if DB_TRX_ID is referring to a transaction that has not been committed.) If a record was inserted in the current transaction, it would be implicitly locked by that transaction. Only if some other transaction is requesting access to the record, the implicit lock should be converted to an explicit one, so that the waits-for graph can be constructed for detecting deadlocks and lock wait timeouts. Before this fix, InnoDB would convert implicit locks to explicit ones, even if no conflict exists. lock_rec_convert_impl_to_expl(): Return whether caller_trx already holds an explicit lock that covers the record. row_vers_impl_x_locked_low(): Avoid a lookup if the record matches caller_trx->id. lock_trx_has_expl_x_lock(): Renamed from lock_trx_has_rec_x_lock(). row_upd_clust_step(): In a debug assertion, check for implicit lock before invoking lock_trx_has_expl_x_lock(). rw_trx_hash_t::find(): Make do_ref_count a mandatory parameter. Assert that trx_id is not 0 (the caller should check it). trx_sys_t::is_registered(): Only invoke find() if id != 0. trx_sys_t::find(): Add the optional parameter do_ref_count. lock_rec_queue_validate(): Avoid lookup for trx_id == 0.	7 years ago
Michael Widenius	a7abddeffa	Create 'main' test directory and move 't' and 'r' there	8 years ago
Alexey Botchkov	9d95b8665a	MDEV-15217 Assertion `thd->transaction.xid_state.xid.is_null()' failed in trans_xa_start. test fixed.	8 years ago
Alexey Botchkov	cd109592ca	MDEV-15217 Assertion `thd->transaction.xid_state.xid.is_null()' failed in trans_xa_start. THD.transaction.xid_state.xid.rm_error should be cleaned as the thread ends.	8 years ago
Alexander Barkov	88a9b23396	MDEV-14609 XA Transction unable to ROLLBACK TO SAVEPOINT The function trans_rollback_to_savepoint(), unlike trans_savepoint(), did not allow xa_state=XA_ACTIVE, so an attempt to do ROLLBCK TO SAVEPOINT inside an XA transaction incorrectly returned an error "...command cannot be executed ... in the ACTIVE state...". Partially merging a MySQL patch: `7fb5c47390` This is WL#7193 (Decouple THD and st_transactions)... The currently merged part includes these changes: - Introducing st_xid_state::check_has_uncommitted_xa() - Reusing it in both trans_rollback_to_savepoint() and trans_savepoint(), so now both allow XA_ACTIVE.	8 years ago
Alexey Botchkov	8ed78cf7f9	xa.test fixed to be thread-stable.	8 years ago
Alexey Botchkov	0acac4fe5f	MDEV-14593 human-readable XA RECOVER. The 'data' field in the XA RECOVER resultset changed to be charset_bin. It seems to me right and also --binary-as-hex starts working. The XA RECOVER FORMAT='SQL' option implemented. It returns the XID string that fits to be an argument for the XA ... statements.	8 years ago
Nirbhay Choubey	3435e8a515	MDEV-7635: Part 1 innodb_autoinc_lock_mode = 2 innodb_buffer_pool_dump_at_shutdown = ON innodb_buffer_pool_dump_pct = 25 innodb_buffer_pool_load_at_startup = ON innodb_checksum_algorithm = CRC32 innodb_file_format = Barracuda innodb_large_prefix = ON innodb_log_compressed_pages = ON innodb_purge_threads = 4 innodb_strict_mode = ON binlog_annotate_row_events = ON binlog_format = MIXED binlog-row-event-max-size = 8192 group_concat_max_len = 1M lock_wait_timeout = 86400 log_slow_admin_statements = ON log_slow_slave_statements = ON log_warnings = 2 max_allowed_packet = 16M replicate_annotate_row_events = ON slave_net_timeout = 60 sync_binlog = 1 aria_recover = BACKUP,QUICK myisam_recover_options = BACKUP,QUICK	9 years ago
Sergey Vojtovich	282497dd6d	MDEV-6720 - enable connection log in mysqltest by default	10 years ago
Dmitry Shulga	2b68b4bc1b	This patch fixes the bug#13737343 (formerly known as 64374): XA TRANSACTIONS AND SAVEPOINT. The bug was introduced by the patch for bug#11766752. This patch sets too strong condition on XA state for SAVEPOINT statement that disallows its execution during XA transaction. But since the statement SAVEPOINT doesn't imply implicit commit we can allow its handling during XA transaction. The patch explicitly check for transaction state against states XA_NOTR and XA_ACTIVE for which the handling of statement SAVEPOINT for XA transaction is allowed. mysql-test/t/xa.test: Testcase was adjusted for bug#13737343. Now SAVEPOINT is allowed for XA transactions in ACTIVE state.	14 years ago
Dmitry Shulga	1a7e7a0f75	This patch fixes the bug#13737343 (formerly known as 64374): XA TRANSACTIONS AND SAVEPOINT. The bug was introduced by the patch for bug#11766752. This patch sets too strong condition on XA state for SAVEPOINT statement that disallows its execution during XA transaction. But since the statement SAVEPOINT doesn't imply implicit commit we can allow its handling during XA transaction. The patch explicitly check for transaction state against states XA_NOTR and XA_ACTIVE for which the handling of statement SAVEPOINT for XA transaction is allowed.	14 years ago
Dmitry Shulga	752496999e	Patch for bug#13070308 - VALGRIND failure in XA test. The issue is that xa.test failed sporadically on some platforms. The reason for the test failure is a race condition in xa.test. The race condition occures between connection that executes statement INSERT INTO t2 SELECT FROM t1 and other connection that tries to run statements DELETE FROM t1 and COMMIT. If COMMIT statement had been executed before the statement INSERT INTO t2 SELECT FROM t1 was locked by lock on table t1 (as a result of query from table t1) then the INSERT statement is executed successfully and a following test for deadlock would failed. This patch fixes this race condition by moving COMMIT statement after commit of distributed transaction from concurrent session.	14 years ago
Dmitry Shulga	716dca03b6	Patch for bug#13070308 - VALGRIND failure in XA test. The issue is that xa.test failed sporadically on some platforms. The reason for the test failure is a race condition in xa.test. The race condition occures between connection that executes statement INSERT INTO t2 SELECT FROM t1 and other connection that tries to run statements DELETE FROM t1 and COMMIT. If COMMIT statement had been executed before the statement INSERT INTO t2 SELECT FROM t1 was locked by lock on table t1 (as a result of query from table t1) then the INSERT statement is executed successfully and a following test for deadlock would failed. This patch fixes this race condition by moving COMMIT statement after commit of distributed transaction from concurrent session.	14 years ago
Vladislav Vaintroub	df48c9bf20	allow changing thread_pool_size without server restart	14 years ago
Sergei Golubchik	b4a0b2c2f8	post-merge fixes. most tests pass. 5.3 merge is next	15 years ago
Jon Olav Hauglid	a5986fa220	Bug#12352846 - TRANS_XA_START(THD*): ASSERTION THD->TRANSACTION.XID_STATE.XID.IS_NULL() FAILED The triggered assert checks that the previous XA transaction has done proper cleanup before a new XA transaction is started. The bug that caused it to be triggered was that XA COMMIT did not clean up error state if XA COMMIT discovered that the current XA transaction had to be rolled back. This patch fixes the problem by resetting the XA error state before XA COMMIT calls ha_rollback_trans(). This allows following XA transactions to be started without triggering the assert. Test case added to xa.test.	15 years ago
Jon Olav Hauglid	889a52d585	Bug#12352846 - TRANS_XA_START(THD*): ASSERTION THD->TRANSACTION.XID_STATE.XID.IS_NULL() FAILED The triggered assert checks that the previous XA transaction has done proper cleanup before a new XA transaction is started. The bug that caused it to be triggered was that XA COMMIT did not clean up error state if XA COMMIT discovered that the current XA transaction had to be rolled back. This patch fixes the problem by resetting the XA error state before XA COMMIT calls ha_rollback_trans(). This allows following XA transactions to be started without triggering the assert. Test case added to xa.test.	15 years ago
Jon Olav Hauglid	94cffe7218	Bug#12348348 - ASSERTION IN ROW0SEL.C LINE 3698: TRX->CONC_STATE == 0 \|\| TRX->CONC_STATE == 1 This bug was a different manifestation of Bug#11766752, which was previously only fixed on mysql-trunk. This patch backports the fix for Bug#11766752 to mysql-5.5, which fixes the problem. The patch also adds some extra test coverage.	15 years ago
Jon Olav Hauglid	ba82398dab	Bug#12348348 - ASSERTION IN ROW0SEL.C LINE 3698: TRX->CONC_STATE == 0 \|\| TRX->CONC_STATE == 1 This bug was a different manifestation of Bug#11766752, which was previously only fixed on mysql-trunk. This patch backports the fix for Bug#11766752 to mysql-5.5, which fixes the problem. The patch also adds some extra test coverage.	15 years ago
Jon Olav Hauglid	3058b8e2a6	Bug #11766788 (former bug 59986) Assert in Diagnostics_area::set_ok_status() for XA COMMIT This assert was triggered if XA COMMIT was issued when an XA transaction already had encountered an error (e.g. a deadlock) which required the XA transaction to be rolled back. In general, the assert is triggered if a statement tries to send OK to the client when an error has already been reported. It was triggered in this case because the trans_xa_commit() function first reported an error, then rolled back the transaction and finally returned FALSE, indicating success. Since trans_xa_commit() reported success, mysql_execute_command() tried to report OK, triggering the assert. This patch fixes the problem by fixing trans_xa_commit() to return TRUE if it encounters an error that requires rollback, even if the rollback itself is successful. Test case added to xa.test.	15 years ago
Jon Olav Hauglid	6688a4f25c	Bug #11766788 (former bug 59986) Assert in Diagnostics_area::set_ok_status() for XA COMMIT This assert was triggered if XA COMMIT was issued when an XA transaction already had encountered an error (e.g. a deadlock) which required the XA transaction to be rolled back. In general, the assert is triggered if a statement tries to send OK to the client when an error has already been reported. It was triggered in this case because the trans_xa_commit() function first reported an error, then rolled back the transaction and finally returned FALSE, indicating success. Since trans_xa_commit() reported success, mysql_execute_command() tried to report OK, triggering the assert. This patch fixes the problem by fixing trans_xa_commit() to return TRUE if it encounters an error that requires rollback, even if the rollback itself is successful. Test case added to xa.test.	15 years ago
Jon Olav Hauglid	5f352c2887	Bug #56448 Assertion failed: ! is_set() with second xa end The problem was that issuing XA END when the XA transaction was already ended, caused an assertion. This assertion tests that the server does not try to send OK to the client if there has already been an error reported. The bug was only noticeable on debug versions of the server. The reason for the problem was that the trans_xa_end() function reported success if the transaction was at XA_IDLE state at the end regardless of any errors occured during processing of trans_xa_end(). So if the transaction state was XA_IDLE already, reported errors would be ignored. This patch fixes the problem by having trans_xa_end() take into consideration any reported errors. The patch also fixes a similar bug with XA PREPARE. Test case added to xa.test.	15 years ago
Jon Olav Hauglid	20b7be9263	Bug #56448 Assertion failed: ! is_set() with second xa end The problem was that issuing XA END when the XA transaction was already ended, caused an assertion. This assertion tests that the server does not try to send OK to the client if there has already been an error reported. The bug was only noticeable on debug versions of the server. The reason for the problem was that the trans_xa_end() function reported success if the transaction was at XA_IDLE state at the end regardless of any errors occured during processing of trans_xa_end(). So if the transaction state was XA_IDLE already, reported errors would be ignored. This patch fixes the problem by having trans_xa_end() take into consideration any reported errors. The patch also fixes a similar bug with XA PREPARE. Test case added to xa.test.	15 years ago
Sergey Vojtovich	2a667b7bcb	An addition to fix for BUG#51342 - more xid crashing Restore autocommit variable by supplying explicit value. mysql-test/r/xa.result: Restore autocommit variable by supplying explicit value. mysql-test/t/xa.test: Restore autocommit variable by supplying explicit value.	16 years ago
Sergey Vojtovich	774cba9505	An addition to fix for BUG#51342 - more xid crashing Restore autocommit variable by supplying explicit value.	16 years ago
Sergey Vojtovich	405fd82207	BUG#51342 - more xid crashing SET autocommit=1 while XA transaction is active may cause various side effects, including memory corruption and server crash. The problem is that SET autocommit=1 and further queries attempt to commit local transaction, whereas XA transaction is still active. As local and XA transactions are mutually exclusive, this patch forbids enabling autocommit mode while XA transaction is active. mysql-test/r/xa.result: A test case for BUG#51342. mysql-test/t/xa.test: A test case for BUG#51342. sql/set_var.cc: Forbid enabling autocommit mode while XA transaction is active.	16 years ago
Sergey Vojtovich	8478e707d9	BUG#51342 - more xid crashing SET autocommit=1 while XA transaction is active may cause various side effects, including memory corruption and server crash. The problem is that SET autocommit=1 and further queries attempt to commit local transaction, whereas XA transaction is still active. As local and XA transactions are mutually exclusive, this patch forbids enabling autocommit mode while XA transaction is active.	16 years ago
Konstantin Osipov	a14bbee5ab	Backport of revno ## 2617.31.1, 2617.31.3, 2617.31.4, 2617.31.5, 2617.31.12, 2617.31.15, 2617.31.15, 2617.31.16, 2617.43.1 - initial changeset that introduced the fix for Bug#989 and follow up fixes for all test suite failures introduced in the initial changeset. ------------------------------------------------------------ revno: 2617.31.1 committer: Davi Arnaut <Davi.Arnaut@Sun.COM> branch nick: 4284-6.0 timestamp: Fri 2009-03-06 19:17:00 -0300 message: Bug#989: If DROP TABLE while there's an active transaction, wrong binlog order WL#4284: Transactional DDL locking Currently the MySQL server does not keep metadata locks on schema objects for the duration of a transaction, thus failing to guarantee the integrity of the schema objects being used during the transaction and to protect then from concurrent DDL operations. This also poses a problem for replication as a DDL operation might be replicated even thought there are active transactions using the object being modified. The solution is to defer the release of metadata locks until a active transaction is either committed or rolled back. This prevents other statements from modifying the table for the entire duration of the transaction. This provides commitment ordering for guaranteeing serializability across multiple transactions. - Incompatible change: If MySQL's metadata locking system encounters a lock conflict, the usual schema is to use the try and back-off technique to avoid deadlocks -- this schema consists in releasing all locks and trying to acquire them all in one go. But in a transactional context this algorithm can't be utilized as its not possible to release locks acquired during the course of the transaction without breaking the transaction commitments. To avoid deadlocks in this case, the ER_LOCK_DEADLOCK will be returned if a lock conflict is encountered during a transaction. Let's consider an example: A transaction has two statements that modify table t1, then table t2, and then commits. The first statement of the transaction will acquire a shared metadata lock on table t1, and it will be kept utill COMMIT to ensure serializability. At the moment when the second statement attempts to acquire a shared metadata lock on t2, a concurrent ALTER or DROP statement might have locked t2 exclusively. The prescription of the current locking protocol is that the acquirer of the shared lock backs off -- gives up all his current locks and retries. This implies that the entire multi-statement transaction has to be rolled back. - Incompatible change: FLUSH commands such as FLUSH PRIVILEGES and FLUSH TABLES WITH READ LOCK won't cause locked tables to be implicitly unlocked anymore. mysql-test/extra/binlog_tests/drop_table.test: Add test case for Bug#989. mysql-test/extra/binlog_tests/mix_innodb_myisam_binlog.test: Fix test case to reflect the fact that transactions now hold metadata locks for the duration of a transaction. mysql-test/include/mix1.inc: Fix test case to reflect the fact that transactions now hold metadata locks for the duration of a transaction. mysql-test/include/mix2.inc: Fix test case to reflect the fact that transactions now hold metadata locks for the duration of a transaction. mysql-test/r/flush_block_commit.result: Update test case result (WL#4284). mysql-test/r/flush_block_commit_notembedded.result: Update test case result (WL#4284). mysql-test/r/innodb.result: Update test case result (WL#4284). mysql-test/r/innodb_mysql.result: Update test case result (WL#4284). mysql-test/r/lock.result: Add test case result for an effect of WL#4284/Bug#989 (all locks should be released when a connection terminates). mysql-test/r/mix2_myisam.result: Update test case result (effects of WL#4284/Bug#989). mysql-test/r/not_embedded_server.result: Update test case result (effects of WL#4284/Bug#989). Add a test case for interaction of WL#4284 and FLUSH PRIVILEGES. mysql-test/r/partition_innodb_semi_consistent.result: Update test case result (effects of WL#4284/Bug#989). mysql-test/r/partition_sync.result: Temporarily disable the test case for Bug#43867, which will be fixed by a subsequent backport. mysql-test/r/ps.result: Add a test case for effect of PREPARE on transactional locks: we take a savepoint at beginning of PREAPRE and release it at the end. Thus PREPARE does not accumulate metadata locks (Bug#989/WL#4284). mysql-test/r/read_only_innodb.result: Update test case result (effects of WL#4284/Bug#989). mysql-test/suite/binlog/r/binlog_row_drop_tbl.result: Add a test case result (WL#4284/Bug#989). mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result: Update test case result (effects of WL#4284/Bug#989). mysql-test/suite/binlog/r/binlog_stm_drop_tbl.result: Add a test case result (WL#4284/Bug#989). mysql-test/suite/binlog/r/binlog_stm_mix_innodb_myisam.result: Update test case result (effects of WL#4284/Bug#989). mysql-test/suite/binlog/r/binlog_unsafe.result: A side effect of Bug#989 -- slightly different table map ids. mysql-test/suite/binlog/t/binlog_row_drop_tbl.test: Add a test case for WL#4284/Bug#989. mysql-test/suite/binlog/t/binlog_stm_drop_tbl.test: Add a test case for WL#4284/Bug#989. mysql-test/suite/binlog/t/binlog_stm_row.test: Update to the new state name. This is actually a follow up to another patch for WL#4284, that changes Locked thread state to Table lock. mysql-test/suite/ndb/r/ndb_index_ordered.result: Remove result for disabled part of the test case. mysql-test/suite/ndb/t/disabled.def: Temporarily disable a test case (Bug#45621). mysql-test/suite/ndb/t/ndb_index_ordered.test: Disable a part of a test case (needs update to reflect semantics of Bug#989). mysql-test/suite/rpl/t/disabled.def: Disable tests made meaningless by transactional metadata locking. mysql-test/suite/sys_vars/r/autocommit_func.result: Add a commit (Bug#989). mysql-test/suite/sys_vars/t/autocommit_func.test: Add a commit (Bug#989). mysql-test/t/flush_block_commit.test: Fix test case to reflect the fact that transactions now hold metadata locks for the duration of a transaction. mysql-test/t/flush_block_commit_notembedded.test: Fix test case to reflect the fact that transactions now hold metadata locks for the duration of a transaction. Add a test case for transaction-scope locks and the global read lock (Bug#989/WL#4284). mysql-test/t/innodb.test: Fix test case to reflect the fact that transactions now hold metadata locks for the duration of a transaction (effects of Bug#989/WL#4284). mysql-test/t/lock.test: Add a test case for Bug#989/WL#4284. mysql-test/t/not_embedded_server.test: Add a test case for Bug#989/WL#4284. mysql-test/t/partition_innodb_semi_consistent.test: Replace TRUNCATE with DELETE, to not issue an implicit commit of a transaction, and not depend on metadata locks. mysql-test/t/partition_sync.test: Temporarily disable the test case for Bug#43867, which needs a fix to be backported from 6.0. mysql-test/t/ps.test: Add a test case for semantics of PREPARE and transaction-scope locks: metadata locks on tables used in PREPARE are enclosed into a temporary savepoint, taken at the beginning of PREPARE, and released at the end. Thus PREPARE does not effect what locks a transaction owns. mysql-test/t/read_only_innodb.test: Fix test case to reflect the fact that transactions now hold metadata locks for the duration of a transaction (Bug#989/WL#4284). Wait for the read_only statement to actually flush tables before sending other concurrent statements that depend on its state. mysql-test/t/xa.test: Fix test case to reflect the fact that transactions now hold metadata locks for the duration of a transaction (Bug#989/WL#4284). sql/ha_ndbcluster_binlog.cc: Backport bits of changes of ha_ndbcluster_binlog.cc from 6.0, to fix the failing binlog test suite with WL#4284. WL#4284 implementation does not work with 5.1 implementation of ndbcluster binlog index. sql/log_event.cc: Release metadata locks after issuing a commit. sql/mdl.cc: Style changes (WL#4284). sql/mysql_priv.h: Rename parameter to match the name used in the definition (WL#4284). sql/rpl_injector.cc: Release metadata locks on commit (WL#4284). sql/rpl_rli.cc: Remove assert made meaningless, metadata locks are released at the end of the transaction. sql/set_var.cc: Close tables and release locks if autocommit mode is set. sql/slave.cc: Release metadata locks after a rollback. sql/sql_acl.cc: Don't implicitly unlock locked tables. Issue a implicit commit at the end and unlock tables. sql/sql_base.cc: Defer the release of metadata locks when closing tables if not required to. Issue a deadlock error if the locking protocol requires that a transaction re-acquire its locks. Release metadata locks when closing tables for reopen. sql/sql_class.cc: Release metadata locks if the thread is killed. sql/sql_parse.cc: Release metadata locks after implicitly committing a active transaction, or after explicit commits or rollbacks. sql/sql_plugin.cc: Allocate MDL request on the stack as the use of the table is contained within the function. It will be removed from the context once close_thread_tables is called at the end of the function. sql/sql_prepare.cc: The problem is that the prepare phase of the CREATE TABLE statement takes a exclusive metadata lock lock and this can cause a self-deadlock the thread already holds a shared lock on the table being that should be created. The solution is to make the prepare phase take a shared metadata lock when preparing a CREATE TABLE statement. The execution of the statement will still acquire a exclusive lock, but won't cause any problem as it issues a implicit commit. After some discussions with stakeholders it has been decided that metadata locks acquired during a PREPARE statement must be released once the statement is prepared even if it is prepared within a multi statement transaction. sql/sql_servers.cc: Don't implicitly unlock locked tables. Issue a implicit commit at the end and unlock tables. sql/sql_table.cc: Close table and release metadata locks after a admin operation. sql/table.h: The problem is that the prepare phase of the CREATE TABLE statement takes a exclusive metadata lock lock and this can cause a self-deadlock the thread already holds a shared lock on the table being that should be created. The solution is to make the prepare phase take a shared metadata lock when preparing a CREATE TABLE statement. The execution of the statement will still acquire a exclusive lock, but won't cause any problem as it issues a implicit commit. sql/transaction.cc: Release metadata locks after the implicitly committed due to a new transaction being started. Also, release metadata locks acquired after a savepoint if the transaction is rolled back to the save point. The problem is that in some cases transaction-long metadata locks could be released before the transaction was committed. This could happen when a active transaction was ended by a "START TRANSACTION" or "BEGIN" statement, in which case the metadata locks would be released before the actual commit of the active transaction. The solution is to defer the release of metadata locks to after the transaction has been implicitly committed. No test case is provided as the effort to provide one is too disproportional to the size of the fix.	16 years ago
Konstantin Osipov	0b39c189ba	Backport of revno ## 2617.31.1, 2617.31.3, 2617.31.4, 2617.31.5, 2617.31.12, 2617.31.15, 2617.31.15, 2617.31.16, 2617.43.1 - initial changeset that introduced the fix for Bug#989 and follow up fixes for all test suite failures introduced in the initial changeset. ------------------------------------------------------------ revno: 2617.31.1 committer: Davi Arnaut <Davi.Arnaut@Sun.COM> branch nick: 4284-6.0 timestamp: Fri 2009-03-06 19:17:00 -0300 message: Bug#989: If DROP TABLE while there's an active transaction, wrong binlog order WL#4284: Transactional DDL locking Currently the MySQL server does not keep metadata locks on schema objects for the duration of a transaction, thus failing to guarantee the integrity of the schema objects being used during the transaction and to protect then from concurrent DDL operations. This also poses a problem for replication as a DDL operation might be replicated even thought there are active transactions using the object being modified. The solution is to defer the release of metadata locks until a active transaction is either committed or rolled back. This prevents other statements from modifying the table for the entire duration of the transaction. This provides commitment ordering for guaranteeing serializability across multiple transactions. - Incompatible change: If MySQL's metadata locking system encounters a lock conflict, the usual schema is to use the try and back-off technique to avoid deadlocks -- this schema consists in releasing all locks and trying to acquire them all in one go. But in a transactional context this algorithm can't be utilized as its not possible to release locks acquired during the course of the transaction without breaking the transaction commitments. To avoid deadlocks in this case, the ER_LOCK_DEADLOCK will be returned if a lock conflict is encountered during a transaction. Let's consider an example: A transaction has two statements that modify table t1, then table t2, and then commits. The first statement of the transaction will acquire a shared metadata lock on table t1, and it will be kept utill COMMIT to ensure serializability. At the moment when the second statement attempts to acquire a shared metadata lock on t2, a concurrent ALTER or DROP statement might have locked t2 exclusively. The prescription of the current locking protocol is that the acquirer of the shared lock backs off -- gives up all his current locks and retries. This implies that the entire multi-statement transaction has to be rolled back. - Incompatible change: FLUSH commands such as FLUSH PRIVILEGES and FLUSH TABLES WITH READ LOCK won't cause locked tables to be implicitly unlocked anymore.	16 years ago
Sergey Vojtovich	17ed708975	BUG#43171 - Assertion failed: thd->transaction.xid_state.xid.is_null() XA START may cause assertion failure/server crash when it is called after unilateral roll back issued by the Resource Manager (both in regular transaction and after XA transaction). The problem was that rm_error variable wasn't set/reset properly. mysql-test/r/xa.result: A test case for BUG#43171. mysql-test/t/xa.test: A test case for BUG#43171. sql/handler.cc: Setting rm_error when we're out of XA transaction has no special meaning. But it blocks reset of thd->transaction.xid structure later. sql/sql_parse.cc: Reset rm_error before we enter ha_rollback(), so thd->transaction.xid strucure is reinitialized.	16 years ago
Sergey Vojtovich	d6f27e58b7	BUG#43171 - Assertion failed: thd->transaction.xid_state.xid.is_null() XA START may cause assertion failure/server crash when it is called after unilateral roll back issued by the Resource Manager (both in regular transaction and after XA transaction). The problem was that rm_error variable wasn't set/reset properly.	16 years ago
Davi Arnaut	eefdd70ab2	Bug#45548: XA transaction without access to InnoDB tables crashes the server The problem is that the one phase commit function failed to properly end a empty transaction. The solution is to ensure that the transaction cleanup procedure is invoked even for empty transactions. mysql-test/r/xa.result: Add test case result for Bug#45548 mysql-test/t/xa.test: Add test case for Bug#45548 sql/handler.cc: Invoke transaction cleanup function whenever a transaction is ended.	17 years ago
Davi Arnaut	4c1333e6ed	Bug#45548: XA transaction without access to InnoDB tables crashes the server The problem is that the one phase commit function failed to properly end a empty transaction. The solution is to ensure that the transaction cleanup procedure is invoked even for empty transactions.	17 years ago
Davi Arnaut	12f91b1d8c	Bug#44672: Assertion failed: thd->transaction.xid_state.xid.is_null() The problem is that when a optimization of read-only transactions (bypass 2-phase commit) was implemented, it removed the code that reseted the XID once a transaction wasn't active anymore: sql/sql_parse.cc: - bzero(&thd->transaction.stmt, sizeof(thd->transaction.stmt)); - if (!thd->active_transaction()) - thd->transaction.xid_state.xid.null(); + thd->transaction.stmt.reset(); This mostly worked fine as the transaction commit and rollback functions (in handler.cc) reset the XID once the transaction is ended. But those functions wouldn't reset the XID in case of a empty transaction, leading to a assertion when a new starting a new XA transaction. The solution is to ensure that the XID state is reset when empty transactions are ended (by either commit or rollback). This is achieved by reorganizing the code so that the transaction cleanup routine is invoked whenever a transaction is ended. mysql-test/r/xa.result: Add test case result for Bug#44672 mysql-test/t/xa.test: Add test case for Bug#44672 sql/handler.cc: Invoke transaction cleanup function whenever a transaction is ended. Move XID state reset logic to the transaction cleanup function. sql/sql_class.h: Add XID state reset logic.	17 years ago
Davi Arnaut	f3e8609960	Bug#44672: Assertion failed: thd->transaction.xid_state.xid.is_null() The problem is that when a optimization of read-only transactions (bypass 2-phase commit) was implemented, it removed the code that reseted the XID once a transaction wasn't active anymore: sql/sql_parse.cc: - bzero(&thd->transaction.stmt, sizeof(thd->transaction.stmt)); - if (!thd->active_transaction()) - thd->transaction.xid_state.xid.null(); + thd->transaction.stmt.reset(); This mostly worked fine as the transaction commit and rollback functions (in handler.cc) reset the XID once the transaction is ended. But those functions wouldn't reset the XID in case of a empty transaction, leading to a assertion when a new starting a new XA transaction. The solution is to ensure that the XID state is reset when empty transactions are ended (by either commit or rollback). This is achieved by reorganizing the code so that the transaction cleanup routine is invoked whenever a transaction is ended.	17 years ago
Matthias Leich	140cc614c9	Last slice of fix for Bug#42003 tests missing the disconnect of connections <> default + Fix for Bug#43114 wait_until_count_sessions too restrictive, random PB failures + Removal of a lot of other weaknesses found + modifications according to review	17 years ago
Matthias Leich	b771483b85	Last slice of fix for Bug#42003 tests missing the disconnect of connections <> default + Fix for Bug#43114 wait_until_count_sessions too restrictive, random PB failures + Removal of a lot of other weaknesses found + modifications according to review	17 years ago
Davi Arnaut	07b7261a70	Post-merge fix: drop table at the end of test. mysql-test/r/xa.result: Update test case result. mysql-test/t/xa.test: Drop table used for test.	17 years ago
Davi Arnaut	e139d9c775	Post-merge fix: drop table at the end of test.	17 years ago
Davi Arnaut	41dd7b6b92	Bug#28323: Server crashed in xid cache operations The problem was that the server did not robustly handle a unilateral roll back issued by the Resource Manager (RM) due to a resource deadlock within the transaction branch. By not acknowledging the roll back, the server (TM) would eventually corrupt the XA transaction state and crash. The solution is to mark the transaction as rollback-only if the RM indicates that it rolled back its branch of the transaction. mysql-test/r/xa.result: Add test case result for Bug#28323 mysql-test/t/xa.test: Add test case for Bug#28323 sql/handler.cc: Reset XID only at the end of the global transaction. sql/share/errmsg.txt: Add new error codes. sql/sql_class.h: Remember the error reported by the Resource Manager. sql/sql_parse.cc: Rollback the transaction if the Resource Manager reported a error and rolled back its branch of the transaction.	17 years ago
Davi Arnaut	b0d673fc4d	Bug#28323: Server crashed in xid cache operations The problem was that the server did not robustly handle a unilateral roll back issued by the Resource Manager (RM) due to a resource deadlock within the transaction branch. By not acknowledging the roll back, the server (TM) would eventually corrupt the XA transaction state and crash. The solution is to mark the transaction as rollback-only if the RM indicates that it rolled back its branch of the transaction.	17 years ago
Davi Arnaut	9ad8d64439	Bug#28323: Server crashed in xid cache operations The problem was that the server did not robustly handle a unilateral roll back issued by the Resource Manager (RM) due to a resource deadlock within the transaction branch. By not acknowledging the roll back, the server (TM) would eventually corrupt the XA transaction state and crash. The solution is to mark the transaction as rollback-only if the RM indicates that it rolled back its branch of the transaction. mysql-test/r/xa.result: Add test case result for Bug#28323 mysql-test/t/xa.test: Add test case for Bug#28323 sql/handler.cc: Reset XID only at the end of the global transaction. sql/share/errmsg.txt: Add new error codes. sql/sql_class.h: Remember the error reported by the Resource Manager. sql/sql_parse.cc: Rollback the transaction if the Resource Manager reported a error and rolled back its branch of the transaction.	17 years ago
Davi Arnaut	ca53651d40	Bug#28323: Server crashed in xid cache operations The problem was that the server did not robustly handle a unilateral roll back issued by the Resource Manager (RM) due to a resource deadlock within the transaction branch. By not acknowledging the roll back, the server (TM) would eventually corrupt the XA transaction state and crash. The solution is to mark the transaction as rollback-only if the RM indicates that it rolled back its branch of the transaction.	17 years ago

16 Commits (8ae462a220b6dee3f493de3cb2fecacfc6ae610c)