Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.2.8
-
None
Description
This is basically a duplicate or a reincarnation of MDEV-117. For some reason, the test innodb.mdev-117 started failing in 10.2.
It is uncertain when this test started failing. The test is nondeterministic, because there is a race condition between the concurrently executing DELETE IGNORE and DELETE statements.
When a deadlock is reported for DELETE IGNORE, the SQL layer would call handler::print_error() but then proceed to the next row, as if no error had happened (which is the purpose of DELETE IGNORE). So, when it proceeded to handler::ha_rnd_next(), InnoDB would hit an assertion failure, because the transaction no longer exists, and we are not executing at the start of a statement.
Attachments
Issue Links
- relates to
-
-
- Closed
-
Activity
It is uncertain when this test started failing.
It first failed with the assertion failure (Assertion `prebuilt->sql_stat_start || trx->state == TRX_STATE_ACTIVE') On July 30th on bb-10.2-mariarocks, once; and has been failing on 10.2 since Aug 7th, 29ad6284918d4be81f40f05214220c42 (RocksDB merge) – 10 times as of now. While it's not 100%-reliable, 10 failures over the past 36 hours and never before is hardly a statistical error.
bb-10.2-marko contains two clean-up commits on top of the actual fix.
elenst, thank you for the observation. Indeed, it looks like
MDEV-117could have been reintroduced by the RocksDB merge done by psergey:PAGER=cat git diff 11948d75862941e2780e550cbc5411895e1cc1c7..29ad6284918d4be81f40f05214220c42 sql/handler.ccNote that the macro `SET_FATAL_ERROR` is assigning a local variable, and due to the `DBUG_VOID_RETURN` that local variable will no longer be examined, so the `SET_FATAL_ERROR` essentially became a no-op here.
The comment of the commit that introduced this change explains that the intention was to provide more detail in the `ER_LOCK_DEADLOCK` message. But why introduce the `DBUG_VOID_RETURN` and skip the fatal-error handling?
commit c90753e671e961269f8d052c35445144abbe1b00Author: Sergei Petrunia <psergey@askmonty.org>Date: Sun Jul 30 09:03:42 2017 +0000Follow the upstream MyRocks: provide details in the ER_LOCK_DEADLOCK messageThis fixes result mismatches in rocksdb.issue111, rocksdb.hermitage,rocksdb.rocksdb_locksdiff --git a/sql/handler.cc b/sql/handler.ccindex a4a2297bd2f..a336d9916f1 100644--- a/sql/handler.cc+++ b/sql/handler.cc@@ -3490,10 +3490,17 @@ void handler::print_error(int error, myf errflag)textno=ER_LOCK_TABLE_FULL;break;case HA_ERR_LOCK_DEADLOCK:- textno=ER_LOCK_DEADLOCK;+ {+ String str, full_err_msg(ER_DEFAULT(ER_LOCK_DEADLOCK), system_charset_info);+/* cannot continue. the statement was already aborted in the engine */SET_FATAL_ERROR;- break;++ get_error_message(error, &str);+ full_err_msg.append(str);+ my_printf_error(ER_LOCK_DEADLOCK, "%s", errflag, full_err_msg.c_ptr_safe());+ DBUG_VOID_RETURN;+ }case HA_ERR_READ_ONLY_TRANSACTION:textno=ER_READ_ONLY_TRANSACTION;