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

main.subselect_no_exists_to_in failed in buildbot

Details

    Description

      http://askmonty.org/buildbot/builders/xenial-amd64-valgrind/builds/256

      main.subselect_no_exists_to_in           w19 [ fail ]
      		 
              Test ended at 2017-01-03 16:55:52
      		 
       
      		 
      CURRENT_TEST: main.subselect_no_exists_to_in
      		 
      /home/buildbot/build/client/mysqltest: Error on delete of '/dev/shm/var/19/tmp/subselect.out.file.1' (Errcode: 2 "No such file or directory")
      		 
      --- /home/buildbot/build/mysql-test/r/subselect_no_exists_to_in.result	2017-01-02 14:29:31.000000000 -0500
      		 
      +++ /home/buildbot/build/mysql-test/r/subselect_no_exists_to_in.reject	2017-01-03 16:55:50.452101900 -0500
      		 
      @@ -7032,7 +7032,7 @@
      		 
       (Select  3 as Revenue, 4 as TemplateID) As `TestCase` 
       Group By  TestCase.Revenue, TestCase.TemplateID;
      		 
       ControlRev
      		 
      -NULL
      		 
      +3
      		 
       #
      		 
       # MDEV-7445:Server crash with Signal 6
      		 
       #
      		 
      @@ -7048,10 +7048,10 @@
      		 
       END |
      		 
       call procedure2();
      		 
       ControlRev
      		 
      -NULL
      		 
      +3
      		 
       call procedure2();
      		 
       ControlRev
      		 
      -NULL
      		 
      +3
      		 
       drop procedure procedure2;
      		 
       SELECT
      		 
       (SELECT user FROM mysql.user
      		 
       
      		 
      mysqltest: Result length mismatch

      Attachments

        Issue Links

          relates to

          Task - A task that needs to be done. MDEV-7069 Fix buildbot failures in main server trees

          • Major - Major loss of function.
          • Stalled

          Activity

            Ascending order - Click to sort in descending order
            elenst Elena Stepanova added a comment -

            The test uses mysql.slow_log in a query, and expects it to be always empty. It does not write anything into the table (it runs with log_output=file, but one of previous tests, main.log_slow, sets log_output=table for a short while. Here is the relevant fragment:

            set long_query_time=0.1;
            		 
            set log_slow_filter='';
            		 
            set global slow_query_log=1;
            		 
            set global log_output='TABLE';
            		 
            select sleep(0.5);
            		 
            select count(*) FROM mysql.slow_log;
            		 
            truncate mysql.slow_log;
            		 
             
            		 
            # Reset used variables
            		 
            set @@long_query_time=default;
            		 
            set global slow_query_log= @org_slow_query_log;
            		 
            set @@log_slow_filter=default;
            		 
            set @@log_slow_verbosity=default;
            		 
            set global log_output= default;

            On a slow builder it might happen that truncate mysql.slow_log itself takes longer than 0.1 sec and will be written into the table. The solution is to do truncate after the variables have been restored to default values.

            elenst Elena Stepanova added a comment - The test uses mysql.slow_log in a query, and expects it to be always empty. It does not write anything into the table (it runs with log_output=file , but one of previous tests, main.log_slow , sets log_output=table for a short while. Here is the relevant fragment: set long_query_time=0.1; set log_slow_filter=''; set global slow_query_log=1; set global log_output='TABLE'; select sleep(0.5); select count(*) FROM mysql.slow_log; truncate mysql.slow_log;   # Reset used variables set @@long_query_time=default; set global slow_query_log= @org_slow_query_log; set @@log_slow_filter=default; set @@log_slow_verbosity=default; set global log_output= default; On a slow builder it might happen that truncate mysql.slow_log itself takes longer than 0.1 sec and will be written into the table. The solution is to do truncate after the variables have been restored to default values.
            elenst Elena Stepanova added a comment -

            https://github.com/MariaDB/server/commit/0912fbbce179cba38bd41de797ba5934e63dbaad

            elenst Elena Stepanova added a comment - https://github.com/MariaDB/server/commit/0912fbbce179cba38bd41de797ba5934e63dbaad

            People

              elenst Elena Stepanova
              elenst Elena Stepanova
              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.