Open GoogleCodeExporter opened 8 years ago
My initial thoughts are that this is caused by the triggers still working while
the table names alter. Table alteration *should* auto-commit any working
trigger.
Additional input I would like to have:
- MySQL version
- on what INSERT value (if possible to tell) the procedure failed, and whether
that value is to be found in the new "b" table.
I'll try repeating the experiment.
Original comment by shlomi.n...@gmail.com
on 22 Feb 2011 at 6:23
test case:
USE test;
DELIMITER ;
DROP TABLE IF EXISTS a;
CREATE TABLE a (
id INT UNSIGNED PRIMARY KEY
);
DELIMITER //
CREATE PROCEDURE doinsert(count INT)
BEGIN
DECLARE counter INT UNSIGNED DEFAULT 0;
WHILE counter < count DO
INSERT INTO a (id) VALUES (counter);
SET counter = counter+1;
END WHILE;
END //
DELIMITER ;
Original comment by shlomi.n...@gmail.com
on 22 Feb 2011 at 7:55
Have managed to get same results using MySQL 5.1.51, table + SP as described
above.
Original comment by shlomi.n...@gmail.com
on 22 Feb 2011 at 2:10
This becomes weirder.
I've added DELAYED logging into some MyISAM "log" table on each trigger
invocation.
Apparently the stored procedure many times (> 50%) fails on:
ERROR 1146 (42S02): Table 'test.log' doesn't exist
even though I do nothing to rename the log table.
I do happen to TRUNCATE it *just before* issuing the procedure.
If I replace the "TRUNCATE log" with "DELETE FROM log", there is no failure on
the log table.
With all invocation of the original problem, and for all occurances of
described bug, there was no difference in the row data of original table &
ghost table (I verified by avoiding dropping the original-renamed-to-arc table,
and comparing max values with ghost-renamed-to-original table).
So my initial thought that this is a trigger failure appears ti be mistaken.
I now have an ugly suspicion, which I'm not sure how to prove, that a stored
procedure does not like the fact a table has been truncated/renamed while (or
just before?!? weird) the procedure is invoked.
I will try to build a test case which is entriely unrelated to
oak-online-alter-table so as to support this claim.
Original comment by shlomi.n...@gmail.com
on 25 Feb 2011 at 6:26
It might be a bug in MySQL's locking.
Original comment by baron.schwartz
on 28 Feb 2011 at 11:48
Still unsure about how to prove/disprove this is a bug with MySQL (as I suspect
it is).
Are you at all waiting on this or does work on mk-osc make this obsolete?
Original comment by shlomi.n...@gmail.com
on 16 Mar 2011 at 6:31
Original issue reported on code.google.com by
baron.schwartz
on 22 Feb 2011 at 1:22