From 9bec7d940cd27c9ea14e1665c4a4fd0ee5890ea7 Mon Sep 17 00:00:00 2001 From: Teemu Ollakka Date: Wed, 20 Feb 2019 09:49:04 +0200 Subject: [PATCH] More graceful error handling in abort_or_interrupt() If abort_or_interrupt() is called in aborting or aborted state, investigate if the transaction was BF aborted. If yes, raise the deadlock error if error has not been set yet and assert in debug build. --- src/transaction.cpp | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/src/transaction.cpp b/src/transaction.cpp index 46fafba..e7f0127 100644 --- a/src/transaction.cpp +++ b/src/transaction.cpp @@ -1013,7 +1013,16 @@ bool wsrep::transaction::abort_or_interrupt( } else if (state() == s_aborting || state() == s_aborted) { - assert(client_state_.current_error()); + // Somehow we got there after BF abort without setting error + // status. This may happen if the DBMS side aborts the transaction + // but still tries to continue processing rows. Raise the error here + // and assert so that the error will be caught in debug builds. + if (bf_abort_client_state_ && + client_state_.current_error() == wsrep::e_success) + { + client_state_.override_error(wsrep::e_deadlock_error); + assert(0); + } return true; } else if (client_service_.interrupted(lock))