database/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2025-07-30 16:24:05 +03:00
Code Activity

Merge 10.6 into 10.11

Browse Source
This commit is contained in:
Marko Mäkelä
2024-08-29 07:47:29 +03:00
parent 22b48bb393 0e76c1ba94
commit cfcf27c6fe
64 changed files with 1527 additions and 1299 deletions
Download Patch File Download Diff File Expand all files Collapse all files

20
sql/rpl_parallel.cc
View File

@ -1496,11 +1496,23 @@ handle_rpl_parallel_thread(void *arg)
after mark_start_commit(), we have to unmark, which has at least a
theoretical possibility of leaving a window where it looks like all
transactions in a GCO have started committing, while in fact one
will need to rollback and retry. This is not supposed to be possible
(since there is a deadlock, at least one transaction should be
blocked from reaching commit), but this seems a fragile ensurance,
and there were historically a number of subtle bugs in this area.
will need to rollback and retry.
Normally this will not happen, since the kill is there to resolve a
deadlock that is preventing at least one transaction from proceeding.
One case it can happen is with InnoDB dict stats update, which can
temporarily cause transactions to block each other, but locks are
released immediately, they don't linger until commit. There could be
other similar cases, there were historically a number of subtle bugs
in this area.
But once we start the commit, we can expect that no new lock
conflicts will be introduced. So by handling any lingering deadlock
kill at this point just before mark_start_commit(), we should be
robust even towards spurious deadlock kills.
*/
if (rgi->killed_for_retry != rpl_group_info::RETRY_KILL_NONE)
wait_for_pending_deadlock_kill(thd, rgi);
if (!thd->killed)
{
DEBUG_SYNC(thd, "rpl_parallel_before_mark_start_commit");