-
Elena Stepanova authored
The failure happens due to a race condition between processing a row event (INSERT) and an automatically generated event DROP TEMPORARY TABLE. Even though DROP has a higher GTID, it can become visible in @@gtid_slave_pos before the row event with a lower GTID has been committed. Since the test makes the slave to synchronize with the master using GTID, the waiting stops as soon as GTID of the DROP TEMPORARY TABLE becomes visible, and if changes from the previous event haven't been applied yet, the error occurs. According to Kristian (see the comment to MDEV-10631), the real problem is that DROP TEMPORARY TABLE is logged in the row mode at all. For this particular test, since DROP does not do anything, nothing prevents it from competing with the prior transaction. The workaround for the test is to add a meaningful event after DROP TEMPORARY TABLE, so that the slave would wait on its GTID instead of the one from DROP. Additionally (unrelated to this problem) removed FLUSH TABLES, which, as the comment stated, should have been removed after MDEV-6403 was fixed.
343ba585