Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-7410

Temporary table name conflict between sessions

    Details

      Description

      If we create a temporary table with the same name within a store procedure, and try to drop some columns in two different sessions running at the same moment, error " Unknown column" may pop.

      Although this is documented in

      https://mariadb.com/kb/en/mariadb/documentation/sql-commands/data-definition/create/create-table/

      "Temporary table names are specific to your session. They may conflict with other temporary tables from other sessions or shadow names of non-temporary tables."

      But this is different behavior with Mysql

      http://dev.mysql.com/doc/refman/5.5/en/create-table.html

      This means that two different sessions can use the same temporary table name without conflicting with each other or with an existing non-TEMPORARY table of the same name. (The existing table is hidden until the temporary table is dropped.)

      This is stopper if using Mariadb as a drop in replacement for Mysql, as this require rewrite all SPs with alter temporary statement.

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

              Hide
              elenst Elena Stepanova added a comment -

              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.

              Show
              elenst Elena Stepanova added a comment - 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.
              Hide
              leomkkwan Leo Kwan added a comment -

              General Log

              Show
              leomkkwan Leo Kwan added a comment - General Log
              Hide
              leomkkwan Leo Kwan added a comment -

              Test SP

              Show
              leomkkwan Leo Kwan added a comment - Test SP
              Hide
              leomkkwan Leo Kwan added a comment - - 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

              Show
              leomkkwan Leo Kwan added a comment - - 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
              Hide
              elenst Elena Stepanova added a comment -

              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.
              
              Show
              elenst Elena Stepanova added a comment - 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.
              Hide
              leomkkwan Leo Kwan added a comment -

              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.

              Show
              leomkkwan Leo Kwan added a comment - 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.
              Hide
              serg Sergei Golubchik added a comment -

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

              Show
              serg Sergei Golubchik added a comment - There are no crashes, as far as I understand, aren't there?
              Hide
              serg Sergei Golubchik added a comment -

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

              Show
              serg Sergei Golubchik added a comment - Okay, I will do a simple workaround for 5.5 and 10.0 branches.
              Hide
              elenst Elena Stepanova added a comment -

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

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

              Show
              elenst Elena Stepanova added a comment - There are no crashes, as far as I understand, aren't there? I didn't observe any crashes while experimenting with it.

                People

                • Assignee:
                  serg Sergei Golubchik
                  Reporter:
                  leomkkwan Leo Kwan
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  4 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved:

                    Time Tracking

                    Estimated:
                    Original Estimate - Not Specified
                    Not Specified
                    Remaining:
                    Remaining Estimate - 0 minutes
                    0m
                    Logged:
                    Time Spent - 30 minutes
                    30m