Bugs in 5.1 smart ALTER TABLE

Ingo,

Thank you for your helpful reply on reporting duplicate key values in smart ALTER TABLE. I finally completed the implementation, but I have some further remarks.

(1) mysql_alter_table() is trying to drop a non-existant table in the
cleanup after calling handler::add_index(). I pointed this out on June 21 and suggested a fix on August 13: <http://lists.mysql.com/internals/34948>. Could someone please reply to that?

(2) MySQL does not seem to roll back the .frm file when handler::add_index()
returns ER_PRIMARY_CANT_HAVE_NULL. I have this in our test case:

create table t1(a int, aa blob, b blob, c text, d text not null) engine=innodb default charset = utf8;

insert into t1 values (null,null,null,null,'null'); insert into t1
select a,aa,left(repeat(d,100*a),65535),repeat(d,20*a),d from t2,t3;

--error ER_PRIMARY_CANT_HAVE_NULL
alter table t1 add primary key (a,aa), add key (b(20)); delete from t1 where d='null';
--error ER_DUP_ENTRY
alter table t1 add primary key (a,aa(255)), add key (b(20));

The latter ALTER TABLE does not lead to handler::add_index() being called, because MySQL thinks that the index definition has changed, from (a,aa) to (a,aa(255)). However, t1 should not have a primary key, because the first ALTER TABLE statement (executed by handler::add_index()) failed.

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.mysql.com Links announce benchmarks bugs certification cluster commits dotnet gui-tools internals java maxdb myodbc mysql mysqldoc packagers perl plusplus replication win32 Request more information about Pantek

If I change the primary key in the first alter table from (a,aa) to
(a,aa(255)), then MySQL will call handler::add_index(). A failed
handler::add_index() should lead into the .frm file being rolled back, shouldn't it? I would have expected MySQL to call handler::add_index() in both cases.

I can supply the definitions and data of t2,t3 if needed, but I don't think it is relevant for reproducing the bug.

This is on bk://mysql.bkbits.net/mysql-5.1, bkf changes|head says:

ChangeSet@1.2541.1.20, 2007-09-21 12:17:09+02:00, gkodinov@macbook.local +1 -0   fixed warnings by bug 30639

ChangeSet@1.2541.1.19, 2007-09-21 10:15:16+02:00, gkodinov@macbook.local +10 -0   fixed type conversion warnings revealed by bug 30639

Best regards,

	Marko Mäkelä
	Innobase Oy/Oracle Corp.

-- 
MySQL Internals Mailing List
For list archives: 
http://lists.mysql.com/internals
To unsubscribe:    
http://lists.mysql.com/internals?unsub=lists@pantek.com