MDEV-33133: MDL conflict handling code should skip BF-aborted trxs

It's possible that MDL conflict handling code is called more
than once for a transaction when:
- it holds more than one conflicting MDL lock
- reschedule_waiters() is executed,
which results in repeated attempts to BF-abort already aborted
transaction.
In such situations, it might be that BF-aborting logic sees
a partially rolled back transaction and erroneously decides
on future actions for such a transaction.

The specific situation tested and fixed is when a SR transaction
applied in the node gets BF-aborted by a started TOI operation.
It's then caught with the server transaction already rolled back,
but with no MDL locks yet released. This caused wrong state
detection for such a transaction during repeated MDL conflict
handling code execution.

Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
This commit is contained in:
Denis Protivensky 2024-01-15 18:25:36 +03:00 committed by Julius Goryavsky
parent d5a669b6b6
commit 4e2c02a12c

View file

@ -3138,8 +3138,6 @@ void wsrep_handle_mdl_conflict(MDL_context *requestor_ctx,
{
DBUG_ASSERT(granted_thd->wsrep_aborter == request_thd->thread_id);
WSREP_DEBUG("BF thread waiting for a victim to release locks");
mysql_mutex_unlock(&granted_thd->LOCK_thd_data);
mysql_mutex_unlock(&granted_thd->LOCK_thd_kill);
}
else if (wsrep_thd_is_toi(granted_thd) ||
wsrep_thd_is_applying(granted_thd))
@ -3218,13 +3216,12 @@ void wsrep_handle_mdl_conflict(MDL_context *requestor_ctx,
}
mysql_mutex_unlock(&granted_thd->LOCK_thd_data);
mysql_mutex_unlock(&granted_thd->LOCK_thd_kill);
DEBUG_SYNC(request_thd, "after_wsrep_thd_abort");
}
else
{
mysql_mutex_unlock(&request_thd->LOCK_thd_data);
}
DEBUG_SYNC(request_thd, "after_wsrep_thd_abort");
}
/**/