Bug #24219 ALTER TABLE ... RENAME TO ... , DISABLE KEYS leads to crash

Submitted: 12 Nov 2006 1:30 Modified: 11 Dec 2006 4:32
Reporter: Hakan Küçükyılmaz Email Updates:
Status: Closed Impact on me:
None 
Category:MySQL Server Severity:S3 (Non-critical)
Version:4.0, 4.1, 5.0, 5.1 OS:Linux (Linux)
Assigned to: Andrey Hristov CPU Architecture:Any

[12 Nov 2006 1:30] Hakan Küçükyılmaz
Description:
I try:
  ALTER TABLE t1 RENAME TO fibonacci, ENABLE KEYS;
but it crashes.

How to repeat:
Test inspired by Andrey Hristov.

SET STORAGE_ENGINE = MyISAM;
DROP TABLE IF EXISTS t1;

CREATE TABLE t1 (a int, b char(10));
INSERT INTO t1 VALUES (1, 'one'), (1, 'one'), (2, 'two'), (3, 'three'), (5,'five'), (8,'eight'), (13, 'thirteen');

ALTER TABLE t1 DISABLE KEYS;
ALTER TABLE t1 ADD INDEX (b);
SELECT * FROM t1 WHERE a BETWEEN 3 AND 6;
EXPLAIN SELECT * FROM t1 WHERE a BETWEEN 3 AND 6;

ALTER TABLE t1 RENAME TO fibonacci, ENABLE KEYS;
SELECT * FROM fibonacci WHERE a BETWEEN 3 AND 6;
EXPLAIN SELECT * FROM fibonacci WHERE a BETWEEN 3 AND 6;

ALTER TABLE fibonacci RENAME TO t1;

# Final cleanup.
DROP TABLE t1;
[12 Nov 2006 1:32] Hakan Küçükyılmaz
Backtrace is:

Program received signal SIGSEGV, Segmentation fault.
0x08368728 in wait_while_table_is_used (thd=0x8942ee0, table=0x895e6e8, 
    function=HA_EXTRA_FORCE_REOPEN) at sql_table.cc:3750
3750      VOID(table->file->extra(function));
(gdb) bt
#0  0x08368728 in wait_while_table_is_used (thd=0x8942ee0, table=0x895e6e8, 
    function=HA_EXTRA_FORCE_REOPEN) at sql_table.cc:3750
#1  0x0836bfd3 in mysql_alter_table (thd=0x8942ee0, new_db=0x8989ad8 "test", 
    new_name=0x8989ae0 "fibonacci", lex_create_info=0x8943500, 
    table_list=0x8989930, fields=@0x8943418, keys=@0x894340c, order_num=0, 
    order=0x0, ignore=false, alter_info=0x8943660, do_send_ok=true)
    at sql_table.cc:5481
#2  0x0827693b in mysql_execute_command (thd=0x8942ee0) at sql_parse.cc:3150
#3  0x0827cee4 in mysql_parse (thd=0x8942ee0, 
    inBuf=0x8989898 "ALTER TABLE t1 RENAME TO fibonacci, ENABLE KEYS", 
    length=47) at sql_parse.cc:6036
#4  0x0827d88e in dispatch_command (command=COM_QUERY, thd=0x8942ee0, 
    packet=0x8981839 "ALTER TABLE t1 RENAME TO fibonacci, ENABLE KEYS", 
    packet_length=48) at sql_parse.cc:1835
#5  0x0827ebbd in do_command (thd=0x8942ee0) at sql_parse.cc:1619
#6  0x0827f06d in handle_one_connection (arg=0x8942ee0) at sql_parse.cc:1234
#7  0x40284297 in start_thread () from /lib/tls/libpthread.so.0
#8  0x4021937e in clone () from /lib/tls/libc.so.6
#9  0x40621bb0 in ?? ()

Regards, Hakan
[15 Nov 2006 14:49] Andrey Hristov
Even simpler repro case :
mysql> create table abc (a int);
Query OK, 0 rows affected (0.13 sec)

mysql> alter table abc rename to def, disable keys;
ERROR 2013 (HY000): Lost connection to MySQL server during query
[16 Nov 2006 11:12] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/15404

ChangeSet@1.2611, 2006-11-16 12:10:55+01:00, andrey@example.com +3 -0
  Fix for bug#24219 ALTER TABLE ... RENAME TO ... , DISABLE KEYS leads to crash
  
  There was an improper order of doing chained operations.
  
  To the documentor: ENABLE|DISABLE KEYS combined with RENAME TO, and no other
  ALTER TABLE clause, leads to server crash independent of the presence of
  indices and data in the table.
[16 Nov 2006 12:12] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/15410

ChangeSet@1.2611, 2006-11-16 13:10:55+01:00, andrey@example.com +3 -0
  Fix for bug#24219 ALTER TABLE ... RENAME TO ... , DISABLE KEYS leads to crash
  
  There was an improper order of doing chained operations.
  
  To the documentor: ENABLE|DISABLE KEYS combined with RENAME TO, and no other
  ALTER TABLE clause, leads to server crash independent of the presence of
  indices and data in the table.
[16 Nov 2006 12:20] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/15412

ChangeSet@1.2611, 2006-11-16 13:18:37+01:00, andrey@example.com +3 -0
  Fix for bug#24219 ALTER TABLE ... RENAME TO ... , DISABLE KEYS leads to crash
  
  There was an improper order of doing chained operations.
  
  To the documentor: ENABLE|DISABLE KEYS combined with RENAME TO, and no other
  ALTER TABLE clause, leads to server crash independent of the presence of
  indices and data in the table.
[16 Nov 2006 13:03] Bugs System
A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/15416

ChangeSet@1.2336, 2006-11-16 14:01:51+01:00, andrey@example.com +2 -0
  Fix for bug#24219 ALTER TABLE ... RENAME TO ... , DISABLE KEYS leads to crash
  (this is the 5.0 patch, because 4.1 differs)
    
  There was an improper order of doing chained operations.
    
  To the documentor: ENABLE|DISABLE KEYS combined with RENAME TO, and no other
  ALTER TABLE clause, leads to server crash independent of the presence of
  indices and data in the table.
[16 Nov 2006 16:18] Andrey Hristov
Pushed into 4.1-maint, 5.0-maint, 5.1-maint
[8 Dec 2006 16:47] Andrey Hristov
The fix will appear as part of 4.1.23 (if released), 5.0.32 (5.0.30 is
already released) and 5.1.15
[11 Dec 2006 4:32] Paul DuBois
Noted in 4.1.23, 5.0.32, 5.1.15 changelogs.

ALTER TABLE statements that performed both RENAME TO and
{ENABLE|DISABLE} KEYS operations caused a server crash.

Portions of this website are copyright © 2001, 2002 The PHP Group

Page generated in 0.044 sec. using MySQL 8.4.7-u6-cloud

Timestamp references displayed by the system are UTC.
Content reproduced on this site is the property of the respective copyright holders.
It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.