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

Assertion `!is_set() || (m_status == DA_OK_BULK && is_bulk_op())' failed in Diagnostics_area::set_ok_status upon ALTER failing due to error from engine

Details

    Description

      --source include/have_innodb.inc
       
      CREATE TABLE t1 (pk INT PRIMARY KEY) ENGINE=InnoDB;
      ALTER TABLE t1 ORDER BY a;
       
      # Cleanup
      DROP TABLE t1;
      

      10.2 32bebfeefb2

      mysqld: /data/src/10.2/sql/sql_error.cc:380: void Diagnostics_area::set_ok_status(ulonglong, ulonglong, const char*): Assertion `!is_set() || (m_status == DA_OK_BULK && is_bulk_op())' failed.
      181115 14:43:37 [ERROR] mysqld got signal 6 ;
       
      #7  0x00007fd087c01ee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
      #8  0x000055ccd93bba47 in Diagnostics_area::set_ok_status (this=0x7fd024005c98, affected_rows=0, last_insert_id=0, message=0x7fd08006b280 "Records: 0  Duplicates: 0  Warnings: 1") at /data/src/10.2/sql/sql_error.cc:380
      #9  0x000055ccd936e2b1 in my_ok (thd=0x7fd024000b00, affected_rows=0, id=0, message=0x7fd08006b280 "Records: 0  Duplicates: 0  Warnings: 1") at /data/src/10.2/sql/sql_class.h:4506
      #10 0x000055ccd94c0549 in mysql_alter_table (thd=0x7fd024000b00, new_db=0x7fd024012b38 "test", new_name=0x0, create_info=0x7fd08006be50, table_list=0x7fd024012528, alter_info=0x7fd08006bda0, order_num=1, order=0x7fd024012c40, ignore=false) at /data/src/10.2/sql/sql_table.cc:9766
      #11 0x000055ccd953a3d7 in Sql_cmd_alter_table::execute (this=0x7fd024012c98, thd=0x7fd024000b00) at /data/src/10.2/sql/sql_alter.cc:329
      #12 0x000055ccd93f1a04 in mysql_execute_command (thd=0x7fd024000b00) at /data/src/10.2/sql/sql_parse.cc:6225
      #13 0x000055ccd93f6865 in mysql_parse (thd=0x7fd024000b00, rawbuf=0x7fd024012448 "ALTER TABLE t1 ORDER BY a", length=25, parser_state=0x7fd08006d200, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:8012
      #14 0x000055ccd93e41af in dispatch_command (command=COM_QUERY, thd=0x7fd024000b00, packet=0x7fd0240966a1 "ALTER TABLE t1 ORDER BY a", packet_length=25, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:1824
      #15 0x000055ccd93e2b12 in do_command (thd=0x7fd024000b00) at /data/src/10.2/sql/sql_parse.cc:1378
      #16 0x000055ccd953506d in do_handle_one_connection (connect=0x55ccdc00fda0) at /data/src/10.2/sql/sql_connect.cc:1335
      #17 0x000055ccd9534dfa in handle_one_connection (arg=0x55ccdc00fda0) at /data/src/10.2/sql/sql_connect.cc:1241
      #18 0x000055ccd995845c in pfs_spawn_thread (arg=0x55ccdc015bb0) at /data/src/10.2/storage/perfschema/pfs.cc:1862
      #19 0x00007fd0896bd494 in start_thread (arg=0x7fd08006e700) at pthread_create.c:333
      #20 0x00007fd087cbe93f in clone () from /lib/x86_64-linux-gnu/libc.so.6
      

      Non-debug build produces the error:

      query 'ALTER TABLE t1 ORDER BY a' failed: 1105: ORDER BY ignored as there is a user-defined clustered index in the table 't1'
      

      Attachments

        Activity

          I do not think that the ORDER BY is even visible to InnoDB. If it were, in the ALGORITHM=INPLACE API, whenever the member functions return true to signal an error, they must have invoked my_error().

          Here, I would guess that the error is somewhere else than in the use of the ALGORITHM=INPLACE API. It might even reproduce with ALGORITHM=COPY.

          marko Marko Mäkelä added a comment - I do not think that the ORDER BY is even visible to InnoDB. If it were, in the ALGORITHM=INPLACE API, whenever the member functions return true to signal an error, they must have invoked my_error() . Here, I would guess that the error is somewhere else than in the use of the ALGORITHM=INPLACE API. It might even reproduce with ALGORITHM=COPY .
          elenst Elena Stepanova added a comment - - edited

          Raised to critical because it badly affects tests.

          elenst Elena Stepanova added a comment - - edited Raised to critical because it badly affects tests.

          Introduced by this commit:

          commit 5f0c31f928338e8a6ffde098b7ffd3d1a8b02903
          Author: Monty <monty@mariadb.org>
          Date:   Tue Jan 10 18:28:24 2017 +0200
           
              MDEV-11597 Assertion when doing select from virtual column with impossible value
          

          by this chunk:

          @@ -1099,24 +1100,23 @@ Sql_condition* THD::raise_condition(uint sql_errno,
                 push_warning and strict SQL_MODE case.
               */
               level= Sql_condition::WARN_LEVEL_ERROR;
          -    killed= KILL_BAD_DATA;
             }
          

          bar Alexander Barkov added a comment - Introduced by this commit: commit 5f0c31f928338e8a6ffde098b7ffd3d1a8b02903 Author: Monty <monty@mariadb.org> Date: Tue Jan 10 18:28:24 2017 +0200   MDEV-11597 Assertion when doing select from virtual column with impossible value by this chunk: @@ -1099,24 +1100,23 @@ Sql_condition* THD::raise_condition(uint sql_errno, push_warning and strict SQL_MODE case. */ level= Sql_condition::WARN_LEVEL_ERROR; - killed= KILL_BAD_DATA; }
          bar Alexander Barkov added a comment - - edited

          The problem is repeatable only when STRICT_ALL_TABLES is set:

          SET sql_mode=STRICT_ALL_TABLES;
          CREATE OR REPLACE TABLE t1 (pk INT PRIMARY KEY) ENGINE=InnoDB;
          ALTER TABLE t1 ORDER BY a;
          

          If I remove STRICT_ALL_TABLES, it works fine:

          SET sql_mode='';
          CREATE OR REPLACE TABLE t1 (pk INT PRIMARY KEY) ENGINE=InnoDB;
          ALTER TABLE t1 ORDER BY a;
          

          Query OK, 0 rows affected, 1 warning (0.07 sec)
          Records: 0  Duplicates: 0  Warnings: 1
          

          I'm curious why this ALTER escalates the warning to error in strict mode.
          Strict mode is about different things (e.g. bad column values).

          One of the possible options would be just to change the message to NOTE.

          bar Alexander Barkov added a comment - - edited The problem is repeatable only when STRICT_ALL_TABLES is set: SET sql_mode=STRICT_ALL_TABLES; CREATE OR REPLACE TABLE t1 (pk INT PRIMARY KEY ) ENGINE=InnoDB; ALTER TABLE t1 ORDER BY a; If I remove STRICT_ALL_TABLES , it works fine: SET sql_mode= '' ; CREATE OR REPLACE TABLE t1 (pk INT PRIMARY KEY ) ENGINE=InnoDB; ALTER TABLE t1 ORDER BY a; Query OK, 0 rows affected, 1 warning (0.07 sec) Records: 0 Duplicates: 0 Warnings: 1 I'm curious why this ALTER escalates the warning to error in strict mode. Strict mode is about different things (e.g. bad column values). One of the possible options would be just to change the message to NOTE.
          bar Alexander Barkov added a comment - - edited

          As agreed with serg, we'll suppress warning-to-error escalation for this message:

          +---------+------+-------------------------------------------------------------------------------+
          | Level   | Code | Message                                                                       |
          +---------+------+-------------------------------------------------------------------------------+
          | Warning | 1105 | ORDER BY ignored as there is a user-defined clustered index in the table 't1' |
          +---------+------+-------------------------------------------------------------------------------+
          

          so this is always returned as a warning (not as an error) even if STRICT_ALL_TABLES is set.

          bar Alexander Barkov added a comment - - edited As agreed with serg , we'll suppress warning-to-error escalation for this message: +---------+------+-------------------------------------------------------------------------------+ | Level | Code | Message | +---------+------+-------------------------------------------------------------------------------+ | Warning | 1105 | ORDER BY ignored as there is a user-defined clustered index in the table 't1' | +---------+------+-------------------------------------------------------------------------------+ so this is always returned as a warning (not as an error) even if STRICT_ALL_TABLES is set.

          People

            bar Alexander Barkov
            elenst Elena Stepanova
            Votes:
            0 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.