| Bug #45775 | Crash when adding primary key to Falcon table with unique constraint. | ||
|---|---|---|---|
| Submitted: | 26 Jun 8:49 | Modified: | 29 Jun 15:25 |
| Reporter: | Dmitri Lenev | ||
| Status: | Patch approved | ||
| Category: | Server: Falcon | Severity: | S3 (Non-critical) |
| Version: | 6.0-bzr | OS: | Any |
| Assigned to: | Christopher Powers | Target Version: | 6.0+ |
| Tags: | F_HANDLER | ||
| Triage: | Triaged: D1 (Critical) | ||
[26 Jun 9:07]
Valeriy Kravchuk
Thank you for the bug report. Verified just as described.
[28 Jun 20:58]
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/77408 2750 Christopher Powers 2009-06-28 Bug #45775, "Crash when adding primary key to Falcon table with unique constraint." There are several issues here: 1) The server assigns TABLE->s->primary_key != MAX_KEY for EITHER a primary key OR a unique key with non-null columns. 2) Falcon assumed ::primary_key unambiguously identifies ONLY the primary key, and therfore incorrectly interpreted (a INT NOT NULL UNIQUE) as being a primary key declaration. 3) Given (2), the command "ALTER TABLE ADD PRIMARY KEY (b)" caused an update conflict for which Falcon raised an exception that subsequently crashed. 4) The crash was caused by a null pointer encountered during exception handling. Item 4 was easy to fix. Item 2, not so easy. Fortunately, the server always names the primary key "PRIMARY", so to distinguish between a primary key and a unique, non-null key, Falcon now checks the key name. added: mysql-test/suite/falcon/r/falcon_bug_45775.result mysql-test/suite/falcon/t/falcon_bug_45775.test modified: storage/falcon/StorageTableShare.cpp storage/falcon/StorageTableShare.h storage/falcon/ha_falcon.cpp storage/falcon/ha_falcon.h
[29 Jun 15:25]
Kevin Lewis
This is another undocumented quirk in the Handler API for pluggable storage engines.
[2 Jul 6:47]
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/77721 2724 Dmitry Lenev 2009-07-02 Bug #45775, "Crash when adding primary key to Falcon table with unique constraint." There are several issues here: 1) The server assigns TABLE->s->primary_key != MAX_KEY for EITHER a primary key OR a unique key with non-null columns. 2) Falcon assumed ::primary_key unambiguously identifies ONLY the primary key, and therfore incorrectly interpreted (a INT NOT NULL UNIQUE) as being a primary key declaration. 3) Given (2), the command "ALTER TABLE ADD PRIMARY KEY (b)" caused an update conflict for which Falcon raised an exception that subsequently crashed. 4) The crash was caused by a null pointer encountered during exception handling. Item 4 was easy to fix. Item 2, not so easy. Fortunately, the server always names the primary key "PRIMARY", so to distinguish between a primary key and a unique, non-null key, Falcon now checks the key name. Manually applied patch from Falcon team tree to mysql-6.1-fk tree.
Description: I am using latest snapshot of mysql-6.0-falcon-team tree. I am trying to execute ALTER TABLE which adds primary key to Falcon table which already has unique key. Server crashes with the following stack-trace: #3 0x08367d58 in handle_segfault (sig=11) at mysqld.cc:2711 #4 <signal handler called> #5 0x086853a8 in Table::getPrimaryKeyName (this=0x0) at Table.cpp:3350 #6 0x0867e166 in StorageTableShare::createIndexName (this=0xb70cfa58, rawName=0xae053da9 "PRIMARY", indexName=0xae053ca8 "", primary=true) at StorageTableShare.cpp:333 #7 0x0866c840 in StorageInterface::getKeyDesc (this=0xb014570, srvTable=0xb014948, indexId=0, indexDesc=0xae053c94) at ha_falcon.cpp:1603 #8 0x0866cd81 in StorageInterface::setIndex (this=0xb014570, srvTable=0xb014948, indexId=0) at ha_falcon.cpp:2718 #9 0x0866ce6b in StorageInterface::remapIndexes (this=0xb014570, srvTable=0xb014948) at ha_falcon.cpp:2756 #10 0x0866daf4 in StorageInterface::addIndex (this=0xb014570, thd=0xb039250, alteredTable=0xb014948, createInfo=0xae054e5c, alterInfo=0xae0542c4, alterFlags=0xae0542a8) at ha_falcon.cpp:2626 #11 0x0866dc4c in StorageInterface::alter_table_phase2 (this=0xb014570, thd=0xb039250, altered_table=0xb014948, create_info=0xae054e5c, alter_info=0xae0542c4, alter_flags=0xae0542a8) at ha_falcon.cpp:2539 #12 0x084e2170 in mysql_fast_or_online_alter_table (thd=0xb039250, table_list=0xb035388, altered_table=0xb014948, create_info=0xae054e5c, alter_info=0xae0542c4, ha_alter_flags=0xae0542a8, keys_onoff=LEAVE_AS_IS) at sql_table.cc:6019 #13 0x084e5be5 in mysql_alter_table (thd=0xb039250, new_db=0xb035590 "test", new_name=0xb035360 "t1", create_info=0xae054e5c, table_list=0xb035388, alter_info=0xae055150, order_num=0, order=0x0, ignore=false) at sql_table.cc:7186 #14 0x0837d15d in mysql_execute_command (thd=0xb039250) at sql_parse.cc:2914 #15 0x083845cc in mysql_parse (thd=0xb039250, inBuf=0xb0350b0 "alter table t1 add primary key (b)", length=34, found_semicolon=0xae055be4) at sql_parse.cc:5979 #16 0x0838514e in dispatch_command (command=COM_QUERY, thd=0xb039250, packet=0xb051ee1 "alter table t1 add primary key (b)", packet_length=34) at sql_parse.cc:1064 #17 0x083866f4 in do_command (thd=0xb039250) at sql_parse.cc:746 #18 0x08371c73 in handle_one_connection (arg=0xb039250) at sql_connect.cc:1146 #19 0xb808850f in start_thread () from /lib/tls/i686/cmov/libpthread.so.0 #20 0xb7e97a0e in clone () from /lib/tls/i686/cmov/libc.so.6 The same works fine for InnoDB and MyISAM. This bug was discovered while working on test coverage for new foreign key implementation. How to repeat: set storage_engine= Falcon; create table t1 (a int not null unique, b int, c int); # The below statement crashes server. alter table t1 add primary key (b);