Bug #10882 | server crashes on "ALTER TABLE ADD" in transaction | ||
---|---|---|---|
Submitted: | 26 May 2005 13:45 | Modified: | 26 May 2005 15:50 |
Reporter: | [ name withheld ] | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | MySQL Server: InnoDB storage engine | Severity: | S1 (Critical) |
Version: | 3.23 | OS: | Windows (XP PRO) |
Assigned to: | CPU Architecture: | Any |
[26 May 2005 13:45]
[ name withheld ]
[26 May 2005 13:51]
Heikki Tuuri
Hi! What does SHOW INNODB STATUS say during the ALTER? Please post a few samples. Could it be that you have not tuned my.cnf or my.ini, and the operation is simply taking long? Does mysqld print anything to the .err log in the datadir? You can, of course, do an ALTER in a transaction, but note that it commits the old transaction, and is run in a transaction of its own. Regards, Heikki
[26 May 2005 15:23]
[ name withheld ]
This is what mysql mysql-_max-nt prints to the err. file, in the data directory: 050526 16:31:59 InnoDB: Warning: MySQL is trying to drop table blunch/#sql2-d88-17d InnoDB: though there are still open handles to it. InnoDB: Adding the table to the background drop queue. 050526 16:41:45 InnoDB: Dropped table blunch/#sql2-d88-17d in background drop queue. 050526 16:45:13 InnoDB: Warning: MySQL is trying to drop table blunch/#sql2-d88-187 InnoDB: though there are still open handles to it. InnoDB: Adding the table to the background drop queue. MySql: ready for connections
[26 May 2005 15:50]
Heikki Tuuri
This bug has probably been fixed in 4.0. Regards, Heikki