Re: Alter table killed, but change was done
Thanks. (I was thrown by the script.)
Between steps 2 and 4 did you do SHOW PROCESSLIST? I would expect to see "Killed" briefly, then the table reverting to the original schema. However, steps 4 and 5 imply that something else happened. (Yeah, that's just a rephrasing of what you have been telling us.)
You have not said whether this table is InnoDB or MyISAM, but I think the actions are similar. NDB Cluster might be different.
Step 3: "tmp table was immediately deleted" -- that sounds like the Unix 'feature' wherein the files are 'unlinked' from the directory you are looking at, so you think they are gone. But, mysqld still has them 'open', so the space is not freed up until they are closed. This would also fit with the error 28s -- mysqld was continuing to write to the (now invisible) file, until it ran out of disk space.
I would have expected the ALTER to do something very similar to your not-used script:
1. Lock
2. Create a new, empty, tmp, table with the appropriate alterations.
3. Do INSERT...SELECT to copy all the data
4. Rename the tmp table into place
6. Unlock
5. DROP the old table.
Step 2 is the only time-consuming step, and the only step that could cause error 28. But, killing step 2 should have prevented the rest of the steps from being performed. Hopefully (but I am not so sure) it would free up the tmp files.
I can't think of any relevance, but what was the definition of myColumn before the ALTER?
I am giving you a long-winded answer with the bottom line of: I don't know why the table was modified anyway.