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

SHOW PROCESSLIST returns empty result set after KILL QUERY

Details

    Description

      --enable_connect_log
       
      --connect (con1,localhost,root,,)
      --let $con_id = `SELECT CONNECTION_ID()`
       
      --echo #
      --echo # This one returns the expected result
      --echo #
      SHOW PROCESSLIST;
       
      --connection default
      eval KILL QUERY $con_id;
       
      --connection con1
      --echo #
      --echo # The one after KILL QUERY returns an empty result set (WRONG)
      --echo #
      SHOW PROCESSLIST;
      --echo #
      --echo # ... and the next one returns the expected result again
      --echo #
      SHOW PROCESSLIST;

      While it is also reproducible on MySQL 5.1-5.6, I'm not filing it upstream, because it's apparently fixed in 5.7 (and hence it has little to no chance to be also fixed in 5.6).

      Attachments

        Issue Links

          Activity

            The reason for this — KILL QUERY that comes when a connection is idle (is not running any query) will kill the next query. What you see is how a killed SHOW PROCESSLIST looks like. If you'd try a SELECT instead, you'd get

            select * from mysql.user;
            ERROR 70100: Query execution was interrupted

            I'll fix SHOW PROCESSLIST to do the same.

            serg Sergei Golubchik added a comment - The reason for this — KILL QUERY that comes when a connection is idle (is not running any query) will kill the next query. What you see is how a killed SHOW PROCESSLIST looks like. If you'd try a SELECT instead, you'd get select * from mysql.user; ERROR 70100: Query execution was interrupted I'll fix SHOW PROCESSLIST to do the same.

            Arguably, KILL QUERY should not affect the next query, only the current one. But should be a subject of a separate bug.

            serg Sergei Golubchik added a comment - Arguably, KILL QUERY should not affect the next query, only the current one. But should be a subject of a separate bug.

            Yes, that's why I filed it as 'Minor' – because the query was not likely to return a meaningful result anyway. The difference is that the error in this situation is annoying, while the empty set is confusing. Confusing is worse.

            But for a side note, the behavior with interrupting the next query is not universal. E.g. if we have SHOW MASTER STATUS or SELECT 1, it works. If a table is involved, e.g. SELECT * FROM mysql.user, it doesn't. I don't know the complete criteria for the difference.

            elenst Elena Stepanova added a comment - Yes, that's why I filed it as 'Minor' – because the query was not likely to return a meaningful result anyway. The difference is that the error in this situation is annoying, while the empty set is confusing. Confusing is worse. But for a side note, the behavior with interrupting the next query is not universal. E.g. if we have SHOW MASTER STATUS or SELECT 1 , it works. If a table is involved, e.g. SELECT * FROM mysql.user , it doesn't. I don't know the complete criteria for the difference.

            People

              serg Sergei Golubchik
              elenst Elena Stepanova
              Votes:
              1 Vote for this issue
              Watchers:
              3 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.