summaryrefslogtreecommitdiff
path: root/mysql-test/r/xa.result
Commit message (Collapse)AuthorAgeFilesLines
* Bug #11766788 (former bug 59986)Jon Olav Hauglid2011-02-141-0/+24
| | | | | | | | | | | | | | | | | | | | | | 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.
* Bug #56448 Assertion failed: ! is_set() with second xa endJon Olav Hauglid2010-09-131-0/+11
| | | | | | | | | | | | | | | | | | | | | 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.
* Merge an addition to BUG51342 5.0-bugteam -> 5.1-bugteam.Sergey Vojtovich2010-03-101-1/+1
|\
| * An addition to fix forSergey Vojtovich2010-03-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | 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.
* | Merge fix for BUG51342 to 5.1-bugteam.Sergey Vojtovich2010-03-101-0/+17
|\ \ | |/
| * BUG#51342 - more xid crashingSergey Vojtovich2010-03-101-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | BUG#43171 - Assertion failed: thd->transaction.xid_state.xid.is_null()Sergey Vojtovich2009-10-281-0/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | Bug#45548: XA transaction without access to InnoDB tables crashes the serverDavi Arnaut2009-06-251-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | Bug#44672: Assertion failed: thd->transaction.xid_state.xid.is_null()Davi Arnaut2009-06-051-0/+6
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Post-merge fix: drop table at the end of test.Davi Arnaut2008-10-211-0/+1
| | | | | | | mysql-test/r/xa.result: Update test case result. mysql-test/t/xa.test: Drop table used for test.
* Bug#28323: Server crashed in xid cache operationsDavi Arnaut2008-10-211-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Bug#12935 Local and XA transactions not mutually exclusiveunknown2005-10-051-2/+10
|
* Bug#13143 - formatID should not affect XID's uniquenessunknown2005-10-051-0/+2
|
* BUG#12162 - one can start two transactions with the same XID.unknown2005-08-121-1/+3
| | | | | | Now we keep all active XID's in a hash
* XID SQL syntaxunknown2005-04-041-0/+45
minor cleanups XA tests include/m_ctype.h: minor cleanup sql/field.cc: minor cleanup sql/handler.cc: XID SQL syntax sql/handler.h: XID SQL syntax sql/item_sum.h: minor cleanup sql/lock.cc: comments sql/sql_class.cc: minor cleanup sql/sql_lex.h: XID SQL syntax sql/sql_parse.cc: XID SQL syntax sql/sql_yacc.yy: XID SQL syntax cleanups