RHEL 6

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.

General Log

Test SP

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

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.

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.

There are no crashes, as far as I understand, aren't there?

Okay, I will do a simple workaround for 5.5 and 10.0 branches.

There are no crashes, as far as I understand, aren't there?

I didn't observe any crashes while experimenting with it.