[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 Created: 2018-11-15  Updated: 2019-02-26  Resolved: 2019-02-26

Status: Closed
Project: MariaDB Server
Component/s: Data Definition - Alter Table, Server, Storage Engine - InnoDB
Affects Version/s: 10.2, 10.3, 10.4
Fix Version/s: 10.2.23, 10.3.14, 10.4.4

Type: Bug Priority: Critical
Reporter: Elena Stepanova Assignee: Alexander Barkov
Resolution: Fixed Votes: 0
Labels: affects-tests


 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'



 Comments   
Comment by Marko Mäkelä [ 2018-11-15 ]

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.

Comment by Elena Stepanova [ 2018-11-19 ]

Raised to critical because it badly affects tests.

Comment by Alexander Barkov [ 2019-02-22 ]

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;
 
   }

Comment by Alexander Barkov [ 2019-02-22 ]

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.

Comment by Alexander Barkov [ 2019-02-26 ]

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.

Generated at Thu Feb 08 08:38:38 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.