Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-4816

rpl.rpl_trunc_temp fails in 10.0-serg

Details

    • Bug
    • Status: Closed (View Workflow)
    • Major
    • Resolution: Fixed
    • 10.0.4
    • None
    • None
    • None

    Description

      rpl.rpl_trunc_temp test fails in 10.0-serg. The failure looks like this:

      CURRENT_TEST: rpl.rpl_trunc_temp
      mysqltest: In included file "./include/wait_for_binlog_event.inc": 
      included from /data0/psergey/dev2/10.0-serg/mysql-test/suite/rpl/t/rpl_trunc_temp.test at line 52:
      At line 33: ERROR: failed while waiting for $wait_binlog_event in binlog 

      In the log, one can see

      **** SHOW BINLOG EVENTS on slave ****
      binlog_name = 'slave-bin.000001'
      SHOW BINLOG EVENTS IN 'slave-bin.000001';
      Log_name        Pos     Event_type      Server_id       End_log_pos     Info
      slave-bin.000001        4       Format_desc     2       248     Server ver: 10.0.3-MariaDB-debug-log, Binlog ver: 4
      slave-bin.000001        248     Gtid_list       2       273     []
      slave-bin.000001        273     Binlog_checkpoint       2       312     slave-bin.000001
      slave-bin.000001        312     Gtid    1       350     GTID 0-1-1
      slave-bin.000001        350     Query   1       446     use `test`; create temporary table t1 (n int)
       
      **** SHOW RELAYLOG EVENTS on slave ****
      relaylog_name = 'slave-relay-bin.000002'
      SHOW RELAYLOG EVENTS IN 'slave-relay-bin.000002';
      Log_name        Pos     Event_type      Server_id       End_log_pos     Info
      slave-relay-bin.000002  4       Format_desc     2       248     Server ver: 10.0.3-MariaDB-debug-log, Binlog ver: 4
      slave-relay-bin.000002  248     Rotate  1       0       master-bin.000001;pos=4
      slave-relay-bin.000002  292     Format_desc     1       248     Server ver: 10.0.3-MariaDB-debug-log, Binlog ver: 4
      slave-relay-bin.000002  536     Gtid_list       1       273     []
      slave-relay-bin.000002  561     Binlog_checkpoint       1       313     master-bin.000001
      slave-relay-bin.000002  601     Gtid    1       351     GTID 0-1-1
      slave-relay-bin.000002  639     Query   1       447     use `test`; create temporary table t1 (n int)
      slave-relay-bin.000002  735     Gtid    1       485     BEGIN GTID 0-1-2
      slave-relay-bin.000002  773     Query   1       572     use `test`; insert into t1 values(1)
      slave-relay-bin.000002  860     Query   1       641     COMMIT
      slave-relay-bin.000002  929     Gtid    1       679     BEGIN GTID 0-1-3
      slave-relay-bin.000002  967     Query   1       756     use `test`; delete from t1
      slave-relay-bin.000002  1044    Query   1       825     COMMIT
      slave-relay-bin.000002  1113    Gtid    1       863     GTID 0-1-4
      slave-relay-bin.000002  1151    Query   1       937     use `test`; truncate t1
      slave-relay-bin.000002  1225    Gtid    1       975     GTID 0-1-5
      slave-relay-bin.000002  1263    Query   1       1085    use `test`; DROP /*!40005 TEMPORARY */ TABLE IF EXISTS `t1`

      Attachments

        Issue Links

          Activity

            Something has gone wrong with this issue. The proposed patch was rejected in review:

            https://lists.launchpad.net/maria-developers/msg05966.html

            However, somehow the patch now nevertheless has ended up in main 10.0

            knielsen Kristian Nielsen added a comment - Something has gone wrong with this issue. The proposed patch was rejected in review: https://lists.launchpad.net/maria-developers/msg05966.html However, somehow the patch now nevertheless has ended up in main 10.0

            Kristian, this was intended. See the review request https://lists.launchpad.net/maria-developers/msg05958.html:

            > In order to get rid of test failures of 10.0-serg, I have pushed the below patch.

            I pushed the patch during your vacation as a way to get the testsuite to pass. After that, you got back and rejected it. I did not act on the rejection, though.

            I've checked the current 10.0 - if I revert the patch for mdev-4816 with "patch -R", the testcase starts to fail again.

            I could act on your review comments, or you can take over for this issue.

            psergei Sergei Petrunia added a comment - Kristian, this was intended. See the review request https://lists.launchpad.net/maria-developers/msg05958.html: > In order to get rid of test failures of 10.0-serg, I have pushed the below patch. I pushed the patch during your vacation as a way to get the testsuite to pass. After that, you got back and rejected it. I did not act on the rejection, though. I've checked the current 10.0 - if I revert the patch for mdev-4816 with "patch -R", the testcase starts to fail again. I could act on your review comments, or you can take over for this issue.

            I pushed to 10.0-base a patch that corrects the GTID code to clear
            the OPTION_BIN_LOG flag rather than set table->no_replicate.

            I still think you should revert the original patch in 10.0.

            (I tried to merge my 10.0-base patch to 10.0 to check if it solves the
            original problem, but there are lots of other unmerged changes that cause a
            lot of unrelated conflicts, so I did not manage to complete the merge).

            knielsen Kristian Nielsen added a comment - I pushed to 10.0-base a patch that corrects the GTID code to clear the OPTION_BIN_LOG flag rather than set table->no_replicate. I still think you should revert the original patch in 10.0. (I tried to merge my 10.0-base patch to 10.0 to check if it solves the original problem, but there are lots of other unmerged changes that cause a lot of unrelated conflicts, so I did not manage to complete the merge).

            Ok. I'm fine with reverting the patch myself, or having someone else revert it.

            I've tried "patch -R" on current 10.0, and it applied. Should I push the reverse patch into 10.0?

            psergei Sergei Petrunia added a comment - Ok. I'm fine with reverting the patch myself, or having someone else revert it. I've tried "patch -R" on current 10.0, and it applied. Should I push the reverse patch into 10.0?

            Pushed a change that reverts my original patch.

            psergei Sergei Petrunia added a comment - Pushed a change that reverts my original patch.

            People

              psergei Sergei Petrunia
              psergei Sergei Petrunia
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.