Elena Stepanova added a comment - 2015-01-06 02:03 You chose 10.0.15-galera as an affected version. Did you really mean this, are you using a Galera cluster? If not, could you please enable the general log; run the flow including creating the temporary table within an SP, and dropping columns in different sessions until you get the error; paste the exact error code/text and the connection number of the session where it occurred; attach the general log. Thanks. Also, regarding the quote from the documentation, I don't think it was meant as an opposite to what MySQL manual says, but I agree it sounds weird. After we figure out why you are getting the error, we'll get the documentation fixed as well.

Leo Kwan added a comment - 2015-01-06 22:40 General Log

Leo Kwan added a comment - 2015-01-06 22:41 Test SP

Leo Kwan added a comment - 2015-01-06 22:46 - edited I am testing on 10.0.15-MariaDB-wsrep-log, and it is a three nodes testing cluster. The general log is attached, I've also attached the store procedure. I open 4 sessions and run the same SP on the same node, the first round ran without error, but error came on the second rounds on 2 out of 4 sessions. This is the exact error message Session 1 MariaDB [(none)] > call PlayGround.procedure1(); ERROR 1054 (42S22): Unknown column 'PlayGround.T_Temp_Test.Value' in 'field list' Session 2 MariaDB [(none)] > call PlayGround.procedure1(); ERROR 1054 (42S22): Unknown column 'PlayGround.T_Temp_Test.MoreValue' in 'field list' Thanks

Elena Stepanova added a comment - 2015-01-09 02:47 Thanks for the data, I was able to reproduce it now. It's a conflict not between sessions, but between several executions of the stored procedures. It's easily repeatable in a single session: drop procedure if exists pr;   --delimiter | create procedure pr(i int ) begin drop table if exists t1; create table t1 (a int , b int ); if (i = 1) then alter table t1 drop a; else alter table t1 drop b; end if ; select * from t1; end | --delimiter ;   call pr(1); call pr(2); It used to be an upstream bug, fixed in 5.6.6 by the following revision: revno: 3857 revision-id: alexander.nozdrin@oracle.com-20120516123641-tnvnhoaimesc8bj9 parent: alexander.nozdrin@oracle.com-20120516110343-36sld7c7somcl3z8 committer: Alexander Nozdrin <alexander.nozdrin@oracle.com> branch nick: trunk-stage.2 timestamp: Wed 2012-05-16 16:36:41 +0400 message: WL#4179: Stored programs: validation of stored program statements. Briefly, that's the implementation of WL#4179. The idea is to remember the original query for SQL-statement within a Stored Programs and re-parse it when meta-data has changed.

Leo Kwan added a comment - 2015-01-10 06:51 Thank you so much on spending time to reproduce this issue and find the root cause. Since there will be relatively long time before 10.1 become production ready. Are there any work around available on this issue so the server may not generate error or random crash? Thanks.

Sergei Golubchik added a comment - 2015-01-10 12:01 There are no crashes, as far as I understand, aren't there?

Sergei Golubchik added a comment - 2015-01-10 12:20 Okay, I will do a simple workaround for 5.5 and 10.0 branches.

Elena Stepanova added a comment - 2015-01-10 13:27 There are no crashes, as far as I understand, aren't there? I didn't observe any crashes while experimenting with it.