Hi Kristian,

That sounds like a good idea to me. Did you mean to use the option for
both primary and replica though, or did you just want `...-slave.opt`?

Brandon

On Sun, Jul 9, 2023 at 7:26 AM Kristian Nielsen <knielsen@knielsen-hq.org> wrote:
Hi Brandon,

The test failure in https://jira.mariadb.org/browse/MDEV-28776 (the one with
10 failed retries after deadlock, not the freebsd failures) seems like it
could be something serious. But it has been very difficult to track down. I
believe you have tried different things, and I also tried hard to reproduce
it, so far without success. But it's still failing occasionally in actual
buildbot runs.

What do you think about pushing the below to the different branches? It
makes the test case log InnoDB information about deadlocks encountered. This
way, when it fails the next time in buildbot we can see 1) what kind of
InnoDB deadlock is triggering the problem, if any; and 2) if it actually
gets a deadlock inside InnoDB 10 times in a row, or if it is something else.

 - Kristian.

-----------------------------------------------------------------------
Author: Kristian Nielsen <knielsen@knielsen-hq.org>
Date:   Sun Jul 9 15:18:03 2023 +0200

    MDEV-28776: rpl.rpl_mark_optimize_tbl_ddl fails with timeout on sync_with_master

    This commit just extends the testcase to include some more information when
    the test failure occurs. The failure has so far only been reproducible in
    buildbot runs.

    Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>
-----------------------------------------------------------------------

diff --git a/mysql-test/suite/rpl/t/rpl_mark_optimize_tbl_ddl.opt b/mysql-test/suite/rpl/t/rpl_mark_optimize_tbl_ddl.opt
new file mode 100644
index 00000000000..3c53d5257b4
--- /dev/null
+++ b/mysql-test/suite/rpl/t/rpl_mark_optimize_tbl_ddl.opt
@@ -0,0 +1 @@
+--innodb-print-all-deadlocks=1