Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.3(EOL), 10.4(EOL), 10.5, 10.6, 10.7(EOL)
-
None
Description
create or replace of both table and sequence are not logged with Gtid event DDL flag
which affects the slave parallel execution.
Unlike other DDL:s these two can occur in concurrent execution with following transactions
which can lead to various errors, including asserts like
(mdl_request->type != MDL_INTENTION_EXCLUSIVE && mdl_request->type != MDL_EXCLUSIVE) || !(get_thd()->rgi_slave && get_thd()->rgi_slave->is_parallel_exec && lock->check_if_conflicting_replication_locks(this) |
|
of MDL_context::acquire_lock
Attachments
Activity
I simplified the commit to withdraw the regular table part. It turns out the stmt level flag is not completely lost in that case. The stmt flag gets merged into all the whole trx flag set and Gtid ctor finds the "all" one. I somewhat missed to read that. In the Sequence case the merging is also done, but "all" gets cleared 'cos of an implicit_commit call before C-o-R Seq eventually gets to executing the ctor. So that part is preserved. The test is also rather trivial now. Pushed to bb-10.3-andrei (as the Seq is added starting from it).
Another execution branch is found to lose the flag. A new commit is coming out.
9e5ea2ef4a9 and its predecessor commits were pushed first to 10.8 QA branch to remove the issue
temporarily.
Patch review. On my end I only would like to see a code comment which explains the expected life-cycle of the flags.
Brandon, this one needs fixing the master side. That's why I test it only there.
Having the DDL flag ensures correct assert-free behaviour like other DDL:s produce.