[MDEV-12847] InnoDB: Error in pars0opt.cc: table test/#sql-5870_3 has prefix_len != 0 Created: 2017-05-19  Updated: 2023-04-27

Status: Confirmed
Project: MariaDB Server
Component/s: Full-text Search, Storage Engine - InnoDB
Affects Version/s: 10.0, 10.1, 10.2, 10.3, 10.4
Fix Version/s: 10.4

Type: Bug Priority: Minor
Reporter: Elena Stepanova Assignee: Thirunarayanan Balathandayuthapani
Resolution: Unresolved Votes: 0
Labels: upstream


 Description    

--source include/have_innodb.inc
 
 
 
CREATE TABLE IF NOT EXISTS t1 (c CHAR(255)) ENGINE = InnoDB;
 
ALTER TABLE t1 ADD FULLTEXT KEY ftidx (c);
 
INSERT INTO t1 VALUES ('foo'),('bar');
 
ALTER TABLE t1 ADD PRIMARY KEY (c(8));
 
 
 
# Cleanup
 
DROP TABLE t1;

10.0 8e1056bce073530e815939ed596581980952d729

 
bug.t8                                   [ fail ]  Found warnings/errors in server log file!
 
        Test ended at 2017-05-19 16:33:06
 
line
 
InnoDB: Error in pars0opt.cc: table test/#sql-58d3_3 has prefix_len != 0
 
^ Found warnings in /data/bld/10.0/mysql-test/var/log/mysqld.1.err

Also reproducible with MySQL 5.6.
Not reproducible with MariaDB 10.2 or MySQL 5.7.
Please feel free to close as "won't fix" if you don't think it's worth fixing.

 Comments   
Comment by Marko Mäkelä [ 2018-05-28 ]

This message was suppressed in MySQL 5.7.1. This change seems questionable to me, because the very purpose of the message seems to be to alert that the InnoDB internal SQL parser assumes that there be no column prefix indexes on the PRIMARY KEY.

This should affect FULLTEXT INDEX in InnoDB only.

The error message is emitted during the ALTER TABLE call, which is rebuilding the table.

10.1 bfed1bfe28980d3b1404f99a44712242a5108ef5

 
#0  opt_clust_access (sel_node=0x7fffac064ea8, n=0)
 
    at /mariadb/10.1/storage/xtradb/pars/pars0opt.cc:1125
 
#1  0x00005555561f1197 in opt_search_plan (sel_node=0x7fffac064ea8)
 
    at /mariadb/10.1/storage/xtradb/pars/pars0opt.cc:1200
 
#2  0x00005555560028e8 in pars_select_statement (select_node=0x7fffac064ea8, 
    table_list=0x7fffac064f88, search_cond=0x7fffac065238, for_update=0x0, 
    lock_shared=0x0, order_by=0x0)
 
    at /mariadb/10.1/storage/xtradb/pars/pars0pars.cc:1079
 
#3  0x00005555561ed802 in yyparse () at pars0grm.y:362
 
#4  0x00005555560043da in pars_sql (info=0x7fffac01da48, 
    str=0x7fffac043f78 "PROCEDURE P() IS\nDECLARE FUNCTION my_func;\nDECLARE CURSOR c IS SELECT FTS_DOC_ID, $sel0 FROM $table_name WHERE FTS_DOC_ID > :doc_id;\nBEGIN\nOPEN c;\nWHILE 1 = 1 LOOP\n  FETCH c INTO my_func();\n  IF c % N"...)
 
    at /mariadb/10.1/storage/xtradb/pars/pars0pars.cc:2245
 
#5  0x00005555561ea0cb in fts_parse_sql (fts_table=0x0, info=0x7fffac01da48, 
    sql=0x7fffac0646e0 "DECLARE FUNCTION my_func;\nDECLARE CURSOR c IS SELECT FTS_DOC_ID, $sel0 FROM $table_name WHERE FTS_DOC_ID > :doc_id;\nBEGIN\nOPEN c;\nWHILE 1 = 1 LOOP\n  FETCH c INTO my_func();\n  IF c % NOTFOUND THEN\n    "...)
 
    at /mariadb/10.1/storage/xtradb/fts/fts0sql.cc:213
 
#6  0x00005555561d2166 in fts_doc_fetch_by_doc_id (get_doc=0x0, doc_id=0, 
    index_to_use=0x7fffac0476c8, option=2, 
    callback=0x5555561d8696 <fts_init_recover_doc(void*, void*)>, 
    arg=0x7fffac061b68) at /mariadb/10.1/storage/xtradb/fts/fts0fts.cc:3774
 
#7  0x00005555561d8d2b in fts_init_index (table=0x7fffac010bf8, 
    has_cache_lock=1) at /mariadb/10.1/storage/xtradb/fts/fts0fts.cc:7691
 
#8  0x00005555561d3d0f in fts_init_doc_id (table=0x7fffac010bf8)
 
    at /mariadb/10.1/storage/xtradb/fts/fts0fts.cc:4947
 
#9  0x00005555561cff8b in fts_get_next_doc_id (table=0x7fffac010bf8, 
    doc_id=0x7ffff41bb9c8) at /mariadb/10.1/storage/xtradb/fts/fts0fts.cc:2684
 
#10 0x000055555604c0e8 in row_mysql_convert_row_to_innobase (
 
    row=0x7fffac01b160, prebuilt=0x7fffac01aaa8, 
    mysql_rec=0x7fffac010e00 "\377foo", ' ' <repeats 196 times>...)
 
    at /mariadb/10.1/storage/xtradb/row/row0mysql.cc:579
 
#11 0x000055555604d959 in row_insert_for_mysql (
 
    mysql_rec=0x7fffac010e00 "\377foo", ' ' <repeats 196 times>..., 
    prebuilt=0x7fffac01aaa8)
 
    at /mariadb/10.1/storage/xtradb/row/row0mysql.cc:1422
 
#12 0x0000555555f3e492 in ha_innobase::write_row (this=0x7fffac04bf80, 
    record=0x7fffac010e00 "\377foo", ' ' <repeats 196 times>...)
 
    at /mariadb/10.1/storage/xtradb/handler/ha_innodb.cc:8886
 
#13 0x0000555555c55849 in handler::ha_write_row (this=0x7fffac04bf80, 
    buf=0x7fffac010e00 "\377foo", ' ' <repeats 196 times>...)
 
    at /mariadb/10.1/sql/handler.cc:5937
 
#14 0x0000555555add384 in copy_data_between_tables (thd=0x555557a86688, 
    from=0x7fffac018e58, to=0x7fffac063238, create=..., ignore=false, 
    order_num=0, order=0x0, copied=0x7ffff41bcae0, deleted=0x7ffff41bcae8, 
    keys_onoff=Alter_info::LEAVE_AS_IS, alter_ctx=0x7ffff41bd780)
 
    at /mariadb/10.1/sql/sql_table.cc:9669

I think that we should treat this as yet another potential bug with InnoDB FULLTEXT INDEX.

Comment by Elena Stepanova [ 2018-09-07 ]

I think if an (ante-mortem) error message has a purpose, it would be to alert a user about something. But the message as it is now is meaningless, nobody who isn't intimately familiar with InnoDB internals can say what it tries to alert about. it should be at least re-written.

Comment by Marko Mäkelä [ 2018-09-10 ]

Well, we could suppress the warning, but first I think that we should test whether FULLTEXT INDEX actually works when the PRIMARY KEY includes a column prefix. This should also involve some code review, so that we can understand any implications.

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