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

Different behaviour for SELECT and DO when KILL QUERY is used

Details

    • Bug
    • Status: Open (View Workflow)
    • Minor
    • Resolution: Unresolved
    • None
    • 10.5, 10.6, 10.11
    • None
    • None

    Description

      The official documentation defines the KILL QUERY statement as:

      KILL QUERY terminates the statement that the connection thread_id is currently executing, but leaves the connection itself intact.

      and defines DO like:

      DO executes the expressions but does not return any results. In most respects, DO is shorthand for SELECT expr, ..., 
      but has the advantage that it is slightly faster when you do not care about the result.

      Based on the documentation above, which doesn't defines what exactly is an statement, I would expect that at least both SELECT and DO are (or not) a statement (i.e both are treated the same way). But when executing something like:

      CREATE EVENT sacrificial_zombie ON SCHEDULE AT CURRENT_TIMESTAMP DO
      		 
      BEGIN 
        SELECT sleep(5);
      		 
        SELECT "Will never be printed if we KILL QUERY during SELECT sleep(5)";
      		 
        SELECT sleep(6);
      		 
      END;

      If the KILL QUERY is executed against the thread running the above event it will result on everything after SELECT sleep(5) not being executed. While if I execute something like:

      CREATE EVENT sacrificial_zombie ON SCHEDULE AT CURRENT_TIMESTAMP DO BEGIN DO sleep(5); DO sleep(6); END;

      and execute KILL QUERY against the thread running the event it will only terminates the execution of DO sleep(5); but the second part DO sleep(6) will be executed.

      Attachments

        Activity

          Ascending order - Click to sort in descending order
          Christianggm Christian Gonzalez created issue -
          Christianggm Christian Gonzalez made changes -
          Field Original Value New Value
          Description The [official documentation|https://mariadb.com/kb/en/kill/] defines the {{KILL QUERY}} statement as:

          {code}
          KILL QUERY terminates the statement that the connection thread_id is currently executing, but leaves the connection itself intact.
          {code}

          and [defines|https://mariadb.com/kb/en/do/] {{DO}} like:

          {code}
          DO executes the expressions but does not return any results. In most respects, DO is shorthand for SELECT expr, ..., but has the advantage that it is slightly faster when you do not care about the result.
          {code}

          Based on the documentation above, which doesn't defines what exactly is an *statement*, I would expect that at least both `SELECT` and `DO` are (or not) a statement (i.e both are treated the same way). But when executing something like:

          {code}
          CREATE EVENT sacrificial_zombie ON SCHEDULE AT CURRENT_TIMESTAMP DO BEGIN SELECT sleep(5); SELECT sleep(6); END;
          {code}

          If the `KILL QUERY` is executed against the thread running the above event it will result on everything after {{SELECT sleep(5)}} not being executed. While if I execute something like:

          {code}
          CREATE EVENT sacrificial_zombie ON SCHEDULE AT CURRENT_TIMESTAMP DO BEGIN DO sleep(5); DO sleep(6); END;
          {code}

          and execute `KILL QUERY` against the thread running the event it will only terminates the execution of `DO sleep(5);` but the second part ` DO sleep(6)` will be executed.           		The [official documentation|https://mariadb.com/kb/en/kill/] defines the {{KILL QUERY}} statement as:

          {code}
          KILL QUERY terminates the statement that the connection thread_id is currently executing, but leaves the connection itself intact.
          {code}

          and [defines|https://mariadb.com/kb/en/do/] {{DO}} like:

          {code}
          DO executes the expressions but does not return any results. In most respects, DO is shorthand for SELECT expr, ..., but has the advantage that it is slightly faster when you do not care about the result.
          {code}

          Based on the documentation above, which doesn't defines what exactly is an *statement*, I would expect that at least both {{SELECT}} and {{DO}} are (or not) a statement (i.e both are treated the same way). But when executing something like:

          {code}
          CREATE EVENT sacrificial_zombie ON SCHEDULE AT CURRENT_TIMESTAMP DO BEGIN SELECT sleep(5); SELECT sleep(6); END;
          {code}

          If the `KILL QUERY` is executed against the thread running the above event it will result on everything after {{SELECT sleep(5)}} not being executed. While if I execute something like:

          {code}
          CREATE EVENT sacrificial_zombie ON SCHEDULE AT CURRENT_TIMESTAMP DO BEGIN DO sleep(5); DO sleep(6); END;
          {code}

          and execute `KILL QUERY` against the thread running the event it will only terminates the execution of `DO sleep(5);` but the second part ` DO sleep(6)` will be executed.
          Christianggm Christian Gonzalez made changes -
          Description The [official documentation|https://mariadb.com/kb/en/kill/] defines the {{KILL QUERY}} statement as:

          {code}
          KILL QUERY terminates the statement that the connection thread_id is currently executing, but leaves the connection itself intact.
          {code}

          and [defines|https://mariadb.com/kb/en/do/] {{DO}} like:

          {code}
          DO executes the expressions but does not return any results. In most respects, DO is shorthand for SELECT expr, ..., but has the advantage that it is slightly faster when you do not care about the result.
          {code}

          Based on the documentation above, which doesn't defines what exactly is an *statement*, I would expect that at least both {{SELECT}} and {{DO}} are (or not) a statement (i.e both are treated the same way). But when executing something like:

          {code}
          CREATE EVENT sacrificial_zombie ON SCHEDULE AT CURRENT_TIMESTAMP DO BEGIN SELECT sleep(5); SELECT sleep(6); END;
          {code}

          If the `KILL QUERY` is executed against the thread running the above event it will result on everything after {{SELECT sleep(5)}} not being executed. While if I execute something like:

          {code}
          CREATE EVENT sacrificial_zombie ON SCHEDULE AT CURRENT_TIMESTAMP DO BEGIN DO sleep(5); DO sleep(6); END;
          {code}

          and execute `KILL QUERY` against the thread running the event it will only terminates the execution of `DO sleep(5);` but the second part ` DO sleep(6)` will be executed.           		The [official documentation|https://mariadb.com/kb/en/kill/] defines the {{KILL QUERY}} statement as:

          {code}
          KILL QUERY terminates the statement that the connection thread_id is currently executing, but leaves the connection itself intact.
          {code}

          and [defines|https://mariadb.com/kb/en/do/] {{DO}} like:

          {code}
          DO executes the expressions but does not return any results. In most respects, DO is shorthand for SELECT expr, ..., but has the advantage that it is slightly faster when you do not care about the result.
          {code}

          Based on the documentation above, which doesn't defines what exactly is an *statement*, I would expect that at least both {{SELECT}} and {{DO}} are (or not) a statement (i.e both are treated the same way). But when executing something like:

          {code}
          CREATE EVENT sacrificial_zombie ON SCHEDULE AT CURRENT_TIMESTAMP DO BEGIN SELECT sleep(5); SELECT sleep(6); END;
          {code}

          If the {{KILL QUERY}} is executed against the thread running the above event it will result on everything after {{SELECT sleep(5)}} not being executed. While if I execute something like:

          {code}
          CREATE EVENT sacrificial_zombie ON SCHEDULE AT CURRENT_TIMESTAMP DO BEGIN DO sleep(5); DO sleep(6); END;
          {code}

          and execute {{KILL QUERY}} against the thread running the event it will only terminates the execution of {{DO sleep(5);}} but the second part {{DO sleep(6)}} will be executed.
          Christianggm Christian Gonzalez made changes -
          Description The [official documentation|https://mariadb.com/kb/en/kill/] defines the {{KILL QUERY}} statement as:

          {code}
          KILL QUERY terminates the statement that the connection thread_id is currently executing, but leaves the connection itself intact.
          {code}

          and [defines|https://mariadb.com/kb/en/do/] {{DO}} like:

          {code}
          DO executes the expressions but does not return any results. In most respects, DO is shorthand for SELECT expr, ..., but has the advantage that it is slightly faster when you do not care about the result.
          {code}

          Based on the documentation above, which doesn't defines what exactly is an *statement*, I would expect that at least both {{SELECT}} and {{DO}} are (or not) a statement (i.e both are treated the same way). But when executing something like:

          {code}
          CREATE EVENT sacrificial_zombie ON SCHEDULE AT CURRENT_TIMESTAMP DO BEGIN SELECT sleep(5); SELECT sleep(6); END;
          {code}

          If the {{KILL QUERY}} is executed against the thread running the above event it will result on everything after {{SELECT sleep(5)}} not being executed. While if I execute something like:

          {code}
          CREATE EVENT sacrificial_zombie ON SCHEDULE AT CURRENT_TIMESTAMP DO BEGIN DO sleep(5); DO sleep(6); END;
          {code}

          and execute {{KILL QUERY}} against the thread running the event it will only terminates the execution of {{DO sleep(5);}} but the second part {{DO sleep(6)}} will be executed.           		The [official documentation|https://mariadb.com/kb/en/kill/] defines the {{KILL QUERY}} statement as:

          {code}
          KILL QUERY terminates the statement that the connection thread_id is currently executing, but leaves the connection itself intact.
          {code}

          and [defines|https://mariadb.com/kb/en/do/] {{DO}} like:

          {code}
          DO executes the expressions but does not return any results. In most respects, DO is shorthand for SELECT expr, ...,
          but has the advantage that it is slightly faster when you do not care about the result.
          {code}

          Based on the documentation above, which doesn't defines what exactly is an *statement*, I would expect that at least both {{SELECT}} and {{DO}} are (or not) a statement (i.e both are treated the same way). But when executing something like:

          {code:sql}
          CREATE EVENT sacrificial_zombie ON SCHEDULE AT CURRENT_TIMESTAMP DO
          BEGIN
            SELECT sleep(5);
            SELECT "Will never be printed if we KILL QUERY during SELECT sleep(5)";
            SELECT sleep(6);
          END;
          {code}

          If the {{KILL QUERY}} is executed against the thread running the above event it will result on everything after {{SELECT sleep(5)}} not being executed. While if I execute something like:

          {code:sql}
          CREATE EVENT sacrificial_zombie ON SCHEDULE AT CURRENT_TIMESTAMP DO BEGIN DO sleep(5); DO sleep(6); END;
          {code}

          and execute {{KILL QUERY}} against the thread running the event it will only terminates the execution of {{DO sleep(5);}} but the second part {{DO sleep(6)}} will be executed.
          serg Sergei Golubchik made changes -
          Assignee Oleksandr Byelkin [ sanja ]
          serg Sergei Golubchik made changes -
          Fix Version/s 10.4 [ 22408 ]
          Fix Version/s 10.5 [ 23123 ]
          Fix Version/s 10.6 [ 24028 ]
          Fix Version/s 10.8 [ 26121 ]
          Fix Version/s 10.9 [ 26905 ]
          Fix Version/s 10.10 [ 27530 ]
          Fix Version/s 10.11 [ 27614 ]
          julien.fritsch Julien Fritsch made changes -
          Fix Version/s 10.8 [ 26121 ]
          julien.fritsch Julien Fritsch made changes -
          Fix Version/s 10.9 [ 26905 ]
          julien.fritsch Julien Fritsch made changes -
          Fix Version/s 10.10 [ 27530 ]
          julien.fritsch Julien Fritsch made changes -
          Fix Version/s 10.4 [ 22408 ]

          People

            sanja Oleksandr Byelkin
            Christianggm Christian Gonzalez
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

              Created:
              Updated:

              Git Integration

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