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

LP:948583 - Stored procedure doesn't not take into account ALTER TABLE, causes wrong result or replication abort

Details

    Description

      The problem is reproducible on all of MariaDB 5.1, 5.2, 5.3, 5.5, MySQL 5.1, 5.5, 5.6, and has also been filed as http://bugs.mysql.com/bug.php?id=64574.

      A stored procedure or a trigger, having been executed once, on the second run might not take into account changes in a table structure, which causes a wrong result on the server where it is run, and also might cause SQL slave abort if the master wrongly returns OK after such a change, while the slave throws the expected error.

      Below are two test cases. The first one is for the basic scenario: the initial execution of the stored procedure ends with the expected error, then the table structure gets fixed, but the procedure fails anyway, with 

      query 'CALL p()' failed: 1054: Unknown column 'test.t2.b' in 'field list'

      The second test case is a reversed scenario – first execution of the procedure runs fine (correctly), then the table structure is altered, and the second execution must fail, but it does not on master; instead, the statement is written in the binlog with error code 0 and later fails on slave, thus causing a replication failure:

      1136 Error 'Column count doesn't match value count at row 1' on query.

      I found the ancient bug http://bugs.mysql.com/bug.php?id=6120 which looks similar, only for views, but it was fixed ages ago.

      Test case 1 (wrong result - the last procedure call fails while it shouldn't)

      CREATE TABLE t1 (a INT);
      		 
      CREATE TABLE t2 (b INT, c INT);
      		 
       
      		 
      --delimiter |
      		 
      CREATE PROCEDURE p()
      		 
      BEGIN
      		 
        INSERT INTO t1 SELECT * FROM t2;
      		 
      END |
      		 
      --delimiter ;
      		 
       
      		 
      --error ER_WRONG_VALUE_COUNT_ON_ROW
      		 
      CALL p();
      		 
      ALTER TABLE t2 DROP COLUMN b;
      		 
      CALL p();
      		 
       

      Test case 2 (replication failure)

      --source include/master-slave.inc
      		 
      CREATE TABLE t1 (a INT);
      		 
      CREATE TABLE t2 (b INT);
      		 
       
      		 
      --delimiter |
      		 
      CREATE PROCEDURE p()
      		 
      BEGIN
      		 
        INSERT INTO t1 SELECT * FROM t2;
      		 
      END |
      		 
      --delimiter ;
      		 
       
      		 
      CALL p();
      		 
      ALTER TABLE t2 ADD COLUMN c INT;
      		 
      CALL p();
      		 
      --sync_slave_with_master
      		 
       

      Attachments

        Issue Links

          duplicates

          Bug - A problem which impairs or prevents the functions of the product. MDEV-11652 SP with cursors does not work well in combination with ALTER TABLE

          • Major - Major loss of function.
          • Closed
          is duplicated by

          Bug - A problem which impairs or prevents the functions of the product. MDEV-15097 Stored procedures are unaware of metadata changes

          • Major - Major loss of function.
          • Closed
          is part of

          Task - A task that needs to be done. MDEV-5242 merge 5.6 bugfixes into 10.0

          • Major - Major loss of function.
          • Closed

          Task - A task that needs to be done. MDEV-5816 MySQL WL#4179 - Stored programs: validation of stored program statements

          • Critical - Crashes, loss of data, severe memory leak.
          • Closed
          relates to

          Bug - A problem which impairs or prevents the functions of the product. MDEV-6488 Autodiscover + CONNECT + OR REPLACE

          • Minor - Minor loss of function, or other problem where easy workaround is present.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-12166 PROCEDURE using a SELECT from a temporary table does not work well

          • Major - Major loss of function.
          • Closed

          Bug - A problem which impairs or prevents the functions of the product. MDEV-21234 Server crashes in in setup_on_expr upon 3rd execution of SP

          • Blocker - Blocks development and/or testing work, production could not run.
          • Closed
          links to

          Web Link Bug #64574 Stored procedure doesn't not notice ALTER TABLE, might cause replication abort

          Activity

            Ascending order - Click to sort in descending order
            elenst Elena Stepanova created issue -
            ratzpo Rasmus Johansson (Inactive) added a comment -

            Launchpad bug id: 948583

            ratzpo Rasmus Johansson (Inactive) added a comment - Launchpad bug id: 948583
            ratzpo Rasmus Johansson (Inactive) made changes -
            Field Original Value New Value
            Labels Launchpad
            ratzpo Rasmus Johansson (Inactive) made changes -
            Labels Launchpad MariaDB_5.1
            ratzpo Rasmus Johansson (Inactive) made changes -
            Labels MariaDB_5.1 Launchpad MariaDB_5.1
            ratzpo Rasmus Johansson (Inactive) made changes -
            Fix Version/s Maria 5.1 [ 11600 ]
            ratzpo Rasmus Johansson (Inactive) made changes -
            Key IMT-7667 MDEV-774
            Project ImportTest [ 10200 ] MariaDB Development [ 10000 ]
            Workflow jira [ 21316 ] defaullt [ 21618 ]
            serg Sergei Golubchik made changes -
            Fix Version/s 5.5.29 [ 11701 ]
            Fix Version/s 5.3.10 [ 11500 ]
            Fix Version/s 5.2.13 [ 10800 ]
            Fix Version/s 5.1.65 [ 10801 ]
            serg Sergei Golubchik made changes -
            Labels Launchpad MariaDB_5.1 Launchpad
            elenst Elena Stepanova made changes -
            Affects Version/s 5.3.9 [ 11000 ]
            serg Sergei Golubchik made changes -
            Fix Version/s 5.1.67 [ 12100 ]
            Fix Version/s 5.1.66 [ 10801 ]
            serg Sergei Golubchik made changes -
            Fix Version/s 5.2.14 [ 12101 ]
            Fix Version/s 5.2.13 [ 10800 ]
            serg Sergei Golubchik made changes -
            Fix Version/s 5.5.29 [ 12102 ]
            Fix Version/s 5.5.28a [ 11701 ]
            serg Sergei Golubchik made changes -
            Fix Version/s 5.3.12 [ 12000 ]
            Fix Version/s 5.3.10 [ 11500 ]
            serg Sergei Golubchik made changes -
            Labels Launchpad Launchpad upstream
            serg Sergei Golubchik added a comment -

            fixed in mysql-5.6.6

            serg Sergei Golubchik added a comment - fixed in mysql-5.6.6
            serg Sergei Golubchik made changes -
            serg Sergei Golubchik made changes -
            Fix Version/s 5.1.68 [ 12600 ]
            Fix Version/s 5.1.67 [ 12100 ]
            serg Sergei Golubchik made changes -
            Fix Version/s 5.2.15 [ 12601 ]
            Fix Version/s 5.2.14 [ 12101 ]
            serg Sergei Golubchik made changes -
            Fix Version/s 5.3.13 [ 12602 ]
            Fix Version/s 5.3.12 [ 12000 ]
            serg Sergei Golubchik made changes -
            Fix Version/s 5.5.30 [ 11800 ]
            Fix Version/s 5.5.29 [ 12102 ]
            serg Sergei Golubchik made changes -
            Fix Version/s 5.5.31 [ 12700 ]
            Fix Version/s 5.5.30 [ 11800 ]
            elenst Elena Stepanova added a comment -

            The upstream bug was fixed in 5.6.6. I think it's okay to have the fix in 10.0 only (after the fix from 5.6 is merged in), so I'm removing 5.x from the 'Fix versions' list.

            elenst Elena Stepanova added a comment - The upstream bug was fixed in 5.6.6. I think it's okay to have the fix in 10.0 only (after the fix from 5.6 is merged in), so I'm removing 5.x from the 'Fix versions' list.
            elenst Elena Stepanova made changes -
            Fix Version/s 10.0.3 [ 12900 ]
            Fix Version/s 5.1.68 [ 12600 ]
            Fix Version/s 5.2.15 [ 12601 ]
            Fix Version/s 5.3.13 [ 12602 ]
            Fix Version/s 5.5.31 [ 12700 ]
            Description The problem is reproducible on all of MariaDB 5.1, 5.2, 5.3, 5.5, MySQL 5.1, 5.5, 5.6, and has also been filed as http://bugs.mysql.com/bug.php?id=64574.

            A stored procedure or a trigger, having been executed once, on the second run might not take into account changes in a table structure, which causes a wrong result on the server where it is run, and also might cause SQL slave abort if the master wrongly returns OK after such a change, while the slave throws the expected error.

            Below are two test cases. The first one is for the basic scenario: the initial execution of the stored procedure ends with the expected error, then the table structure gets fixed, but the procedure fails anyway, with

            query 'CALL p()' failed: 1054: Unknown column 'test.t2.b' in 'field list'

            The second test case is a reversed scenario -- first execution of the procedure runs fine (correctly), then the table structure is altered, and the second execution must fail, but it does not on master; instead, the statement is written in the binlog with error code 0 and later fails on slave, thus causing a replication failure:

            1136 Error 'Column count doesn't match value count at row 1' on query.

            I found the ancient bug http://bugs.mysql.com/bug.php?id=6120 which looks similar, only for views, but it was fixed ages ago.

            # Test case 1 (wrong result)

            CREATE TABLE t1 (a INT);
            CREATE TABLE t2 (b INT, c INT);

            --delimiter |
            CREATE PROCEDURE p()
            BEGIN
              INSERT INTO t1 SELECT * FROM t2;
            END |
            --delimiter ;

            --error ER_WRONG_VALUE_COUNT_ON_ROW
            CALL p();
            ALTER TABLE t2 DROP COLUMN b;
            CALL p();

            # End of test case 1

            ##############

            # Test case 2 (replication failure)

            --source include/master-slave.inc
            CREATE TABLE t1 (a INT);
            CREATE TABLE t2 (b INT);

            --delimiter |
            CREATE PROCEDURE p()
            BEGIN
              INSERT INTO t1 SELECT * FROM t2;
            END |
            --delimiter ;

            CALL p();
            ALTER TABLE t2 ADD COLUMN c INT;
            CALL p();
            --sync_slave_with_master

            # End of test case 2             		The problem is reproducible on all of MariaDB 5.1, 5.2, 5.3, 5.5, MySQL 5.1, 5.5, 5.6, and has also been filed as http://bugs.mysql.com/bug.php?id=64574.

            A stored procedure or a trigger, having been executed once, on the second run might not take into account changes in a table structure, which causes a wrong result on the server where it is run, and also might cause SQL slave abort if the master wrongly returns OK after such a change, while the slave throws the expected error.

            Below are two test cases. The first one is for the basic scenario: the initial execution of the stored procedure ends with the expected error, then the table structure gets fixed, but the procedure fails anyway, with

            {noformat}
            query 'CALL p()' failed: 1054: Unknown column 'test.t2.b' in 'field list'
            {noformat}

            The second test case is a reversed scenario -- first execution of the procedure runs fine (correctly), then the table structure is altered, and the second execution must fail, but it does not on master; instead, the statement is written in the binlog with error code 0 and later fails on slave, thus causing a replication failure:

            {noformat}
            1136 Error 'Column count doesn't match value count at row 1' on query.
            {noformat}

            I found the ancient bug http://bugs.mysql.com/bug.php?id=6120 which looks similar, only for views, but it was fixed ages ago.

            Test case 1 (wrong result)

            {code:sql}
            CREATE TABLE t1 (a INT);
            CREATE TABLE t2 (b INT, c INT);

            --delimiter |
            CREATE PROCEDURE p()
            BEGIN
              INSERT INTO t1 SELECT * FROM t2;
            END |
            --delimiter ;

            --error ER_WRONG_VALUE_COUNT_ON_ROW
            CALL p();
            ALTER TABLE t2 DROP COLUMN b;
            CALL p();

            {code}

            Test case 2 (replication failure)

            {code:sql}
            --source include/master-slave.inc
            CREATE TABLE t1 (a INT);
            CREATE TABLE t2 (b INT);

            --delimiter |
            CREATE PROCEDURE p()
            BEGIN
              INSERT INTO t1 SELECT * FROM t2;
            END |
            --delimiter ;

            CALL p();
            ALTER TABLE t2 ADD COLUMN c INT;
            CALL p();
            --sync_slave_with_master

            {code}
            elenst Elena Stepanova made changes -
            elenst Elena Stepanova made changes -
            serg Sergei Golubchik made changes -
            Fix Version/s 10.0.4 [ 13101 ]
            Fix Version/s 10.0.3 [ 12900 ]
            serg Sergei Golubchik made changes -
            Fix Version/s 10.0.5 [ 13201 ]
            Fix Version/s 10.0.4 [ 13101 ]
            serg Sergei Golubchik made changes -
            Fix Version/s 10.0.6 [ 13202 ]
            Fix Version/s 10.0.5 [ 13201 ]
            serg Sergei Golubchik made changes -
            Fix Version/s 10.0.7 [ 14100 ]
            Fix Version/s 10.0.6 [ 13202 ]
            serg Sergei Golubchik made changes -
            Fix Version/s 10.0.8 [ 14200 ]
            Fix Version/s 10.0.7 [ 14100 ]
            serg Sergei Golubchik made changes -
            serg Sergei Golubchik made changes -
            Fix Version/s 10.0.9 [ 14400 ]
            Fix Version/s 10.0.8 [ 14200 ]
            serg Sergei Golubchik made changes -
            Fix Version/s 10.0.10 [ 14500 ]
            Fix Version/s 10.0.9 [ 14400 ]
            serg Sergei Golubchik made changes -
            Fix Version/s 10.0.11 [ 15200 ]
            Fix Version/s 10.0.10 [ 14500 ]
            serg Sergei Golubchik made changes -
            Fix Version/s 10.0.12 [ 15201 ]
            Fix Version/s 10.0.11 [ 15200 ]
            serg Sergei Golubchik made changes -
            Workflow defaullt [ 21618 ] MariaDB v2 [ 43200 ]
            serg Sergei Golubchik made changes -
            Fix Version/s 10.0.13 [ 16000 ]
            Fix Version/s 10.0.12 [ 15201 ]
            elenst Elena Stepanova added a comment -

            Still reproducible on current 10.0 (10.0.14+, revno 4471).

            Upstream bug was fixed in 5.6.6, apparently as a part of http://dev.mysql.com/worklog/task/?id=4179

            evno: 3857
            		 
            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.

            It might be too big to get it in 10.0, but maybe 10.1 is okay, since it's not a feature as such, but a big fat bugfix.

            elenst Elena Stepanova added a comment - Still reproducible on current 10.0 (10.0.14+, revno 4471). Upstream bug was fixed in 5.6.6, apparently as a part of http://dev.mysql.com/worklog/task/?id=4179 evno: 3857 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. It might be too big to get it in 10.0, but maybe 10.1 is okay, since it's not a feature as such, but a big fat bugfix.
            elenst Elena Stepanova made changes -
            Fix Version/s 10.1 [ 16100 ]
            Fix Version/s 10.0 [ 16000 ]
            Affects Version/s 5.3.12 [ 12000 ]
            Affects Version/s 10.0 [ 16000 ]
            Affects Version/s 5.5 [ 15800 ]
            Labels Launchpad upstream Launchpad upstream-fixed
            Priority Minor [ 4 ] Major [ 3 ]
            elenst Elena Stepanova made changes -
            elenst Elena Stepanova made changes -
            Description The problem is reproducible on all of MariaDB 5.1, 5.2, 5.3, 5.5, MySQL 5.1, 5.5, 5.6, and has also been filed as http://bugs.mysql.com/bug.php?id=64574.

            A stored procedure or a trigger, having been executed once, on the second run might not take into account changes in a table structure, which causes a wrong result on the server where it is run, and also might cause SQL slave abort if the master wrongly returns OK after such a change, while the slave throws the expected error.

            Below are two test cases. The first one is for the basic scenario: the initial execution of the stored procedure ends with the expected error, then the table structure gets fixed, but the procedure fails anyway, with

            {noformat}
            query 'CALL p()' failed: 1054: Unknown column 'test.t2.b' in 'field list'
            {noformat}

            The second test case is a reversed scenario -- first execution of the procedure runs fine (correctly), then the table structure is altered, and the second execution must fail, but it does not on master; instead, the statement is written in the binlog with error code 0 and later fails on slave, thus causing a replication failure:

            {noformat}
            1136 Error 'Column count doesn't match value count at row 1' on query.
            {noformat}

            I found the ancient bug http://bugs.mysql.com/bug.php?id=6120 which looks similar, only for views, but it was fixed ages ago.

            Test case 1 (wrong result)

            {code:sql}
            CREATE TABLE t1 (a INT);
            CREATE TABLE t2 (b INT, c INT);

            --delimiter |
            CREATE PROCEDURE p()
            BEGIN
              INSERT INTO t1 SELECT * FROM t2;
            END |
            --delimiter ;

            --error ER_WRONG_VALUE_COUNT_ON_ROW
            CALL p();
            ALTER TABLE t2 DROP COLUMN b;
            CALL p();

            {code}

            Test case 2 (replication failure)

            {code:sql}
            --source include/master-slave.inc
            CREATE TABLE t1 (a INT);
            CREATE TABLE t2 (b INT);

            --delimiter |
            CREATE PROCEDURE p()
            BEGIN
              INSERT INTO t1 SELECT * FROM t2;
            END |
            --delimiter ;

            CALL p();
            ALTER TABLE t2 ADD COLUMN c INT;
            CALL p();
            --sync_slave_with_master

            {code}             		The problem is reproducible on all of MariaDB 5.1, 5.2, 5.3, 5.5, MySQL 5.1, 5.5, 5.6, and has also been filed as http://bugs.mysql.com/bug.php?id=64574.

            A stored procedure or a trigger, having been executed once, on the second run might not take into account changes in a table structure, which causes a wrong result on the server where it is run, and also might cause SQL slave abort if the master wrongly returns OK after such a change, while the slave throws the expected error.

            Below are two test cases. The first one is for the basic scenario: the initial execution of the stored procedure ends with the expected error, then the table structure gets fixed, but the procedure fails anyway, with

            {noformat}
            query 'CALL p()' failed: 1054: Unknown column 'test.t2.b' in 'field list'
            {noformat}

            The second test case is a reversed scenario -- first execution of the procedure runs fine (correctly), then the table structure is altered, and the second execution must fail, but it does not on master; instead, the statement is written in the binlog with error code 0 and later fails on slave, thus causing a replication failure:

            {noformat}
            1136 Error 'Column count doesn't match value count at row 1' on query.
            {noformat}

            I found the ancient bug http://bugs.mysql.com/bug.php?id=6120 which looks similar, only for views, but it was fixed ages ago.

            Test case 1 (wrong result - the last procedure call fails while it shouldn't)

            {code:sql}
            CREATE TABLE t1 (a INT);
            CREATE TABLE t2 (b INT, c INT);

            --delimiter |
            CREATE PROCEDURE p()
            BEGIN
              INSERT INTO t1 SELECT * FROM t2;
            END |
            --delimiter ;

            --error ER_WRONG_VALUE_COUNT_ON_ROW
            CALL p();
            ALTER TABLE t2 DROP COLUMN b;
            CALL p();

            {code}

            Test case 2 (replication failure)

            {code:sql}
            --source include/master-slave.inc
            CREATE TABLE t1 (a INT);
            CREATE TABLE t2 (b INT);

            --delimiter |
            CREATE PROCEDURE p()
            BEGIN
              INSERT INTO t1 SELECT * FROM t2;
            END |
            --delimiter ;

            CALL p();
            ALTER TABLE t2 ADD COLUMN c INT;
            CALL p();
            --sync_slave_with_master

            {code}
            elenst Elena Stepanova made changes -
            Component/s Data Definition - Alter Table [ 10114 ]
            elenst Elena Stepanova made changes -
            Labels Launchpad upstream-fixed Launchpad upstream-fixed verified
            ratzpo Rasmus Johansson (Inactive) made changes -
            Workflow MariaDB v2 [ 43200 ] MariaDB v3 [ 65213 ]
            serg Sergei Golubchik made changes -
            serg Sergei Golubchik made changes -
            Fix Version/s 10.1 [ 16100 ]
            elenst Elena Stepanova added a comment -

            serg, some time ago you unset 'Fix version/s' on this report, was there a reason for that – should we close it as 'Won't fix', or target for 10.2, or...?

            elenst Elena Stepanova added a comment - serg , some time ago you unset 'Fix version/s' on this report, was there a reason for that – should we close it as 'Won't fix', or target for 10.2, or...?
            serg Sergei Golubchik added a comment -

            We'll fix it, but 10.2 is unlikely, that's why I've unset the version.

            serg Sergei Golubchik added a comment - We'll fix it, but 10.2 is unlikely, that's why I've unset the version.
            elenst Elena Stepanova made changes -
            Status Open [ 1 ] Confirmed [ 10101 ]
            elenst Elena Stepanova made changes -
            Assignee Alexander Barkov [ bar ]
            elenst Elena Stepanova made changes -
            bar Alexander Barkov added a comment -

            The same problem is repeatable with cursors:

            SET sql_mode=DEFAULT;
            		 
            DROP TABLE IF EXISTS t1;
            		 
            CREATE TABLE t1 (a INT, b VARCHAR(10));
            		 
            INSERT INTO t1 VALUES (10,20);
            		 
             
            		 
            DROP PROCEDURE IF EXISTS p1;
            		 
            DELIMITER $$
            		 
            CREATE PROCEDURE p1()
            		 
            BEGIN
            		 
              DECLARE a,b INT;
            		 
              DECLARE cur CURSOR FOR SELECT * FROM t1;
            		 
              OPEN cur;
            		 
              FETCH cur INTO a,b;
            		 
              CLOSE cur;
            		 
              SELECT a,b;
            		 
            END;
            		 
            $$
            		 
            DELIMITER ;
            		 
            CALL p1();

            The above script returns:

            +------+------+
            		 
            | a    | b    |
            		 
            +------+------+
            		 
            |   10 |   20 |
            		 
            +------+------+

            So far so good.

            Now I add a new column to the table and call the procedure again

            ALTER TABLE t1 ADD c INT;
            		 
            CALL p1();

            Oops. It returns the result, like if the table still had 2 columns.
            It should fail, because there are now 3 columns in the table.

            bar Alexander Barkov added a comment - The same problem is repeatable with cursors: SET sql_mode= DEFAULT ; DROP TABLE IF EXISTS t1; CREATE TABLE t1 (a INT , b VARCHAR (10)); INSERT INTO t1 VALUES (10,20);   DROP PROCEDURE IF EXISTS p1; DELIMITER $$ CREATE PROCEDURE p1() BEGIN DECLARE a,b INT ; DECLARE cur CURSOR FOR SELECT * FROM t1; OPEN cur; FETCH cur INTO a,b; CLOSE cur; SELECT a,b; END ; $$ DELIMITER ; CALL p1(); The above script returns: +------+------+ | a | b | +------+------+ | 10 | 20 | +------+------+ So far so good. Now I add a new column to the table and call the procedure again ALTER TABLE t1 ADD c INT ; CALL p1(); Oops. It returns the result, like if the table still had 2 columns. It should fail, because there are now 3 columns in the table.
            bar Alexander Barkov made changes -
            bar Alexander Barkov made changes -
            serg Sergei Golubchik made changes -
            Fix Version/s 10;4 [ 22633 ]
            serg Sergei Golubchik made changes -
            Fix Version/s 10.4 [ 22408 ]
            Fix Version/s 10;4 [ 22633 ]
            serg Sergei Golubchik made changes -
            Assignee Alexander Barkov [ bar ]
            hholzgra Hartmut Holzgraefe added a comment -

            See also: http://alexandernozdrin.blogspot.de/2012/09/mysql-56-handling-metadata-changes-in.html

            hholzgra Hartmut Holzgraefe added a comment - See also: http://alexandernozdrin.blogspot.de/2012/09/mysql-56-handling-metadata-changes-in.html
            elenst Elena Stepanova made changes -
            midenok Aleksey Midenkov made changes -
            julien.fritsch Julien Fritsch made changes -
            serg Sergei Golubchik made changes -
            Workflow MariaDB v3 [ 65213 ] MariaDB v4 [ 143813 ]
            alice Alice Sherepa made changes -
            Affects Version/s 10.3 [ 22126 ]
            Affects Version/s 10.4 [ 22408 ]
            Affects Version/s 10.5 [ 23123 ]
            Affects Version/s 10.6 [ 24028 ]
            Affects Version/s 10.7 [ 24805 ]
            Affects Version/s 10.8 [ 26121 ]
            Affects Version/s 10.9 [ 26905 ]
            Affects Version/s 10.10 [ 27530 ]
            alice Alice Sherepa made changes -
            Fix Version/s 10.3 [ 22126 ]
            Fix Version/s 10.5 [ 23123 ]
            Fix Version/s 10.6 [ 24028 ]
            Fix Version/s 10.7 [ 24805 ]
            Fix Version/s 10.8 [ 26121 ]
            Fix Version/s 10.9 [ 26905 ]
            alice Alice Sherepa made changes -
            Assignee Sergei Golubchik [ serg ]
            serg Sergei Golubchik made changes -
            Assignee Sergei Golubchik [ serg ] Dmitry Shulga [ JIRAUSER47315 ]
            julien.fritsch Julien Fritsch made changes -
            Fix Version/s 10.7 [ 24805 ]
            julien.fritsch Julien Fritsch made changes -
            Fix Version/s 10.3 [ 22126 ]
            julien.fritsch Julien Fritsch made changes -
            Fix Version/s 10.8 [ 26121 ]
            julien.fritsch Julien Fritsch made changes -
            Fix Version/s 10.9 [ 26905 ]
            julien.fritsch Julien Fritsch made changes -
            Fix Version/s 10.4 [ 22408 ]
            alice Alice Sherepa made changes -
            Fix Version/s 10.11 [ 27614 ]
            alice Alice Sherepa made changes -
            Labels Launchpad upstream-fixed verified Launchpad not-11.2+ upstream-fixed verified
            alice Alice Sherepa made changes -
            serg Sergei Golubchik added a comment -

            No longer repeatable after MDEV-5861

            serg Sergei Golubchik added a comment - No longer repeatable after MDEV-5861
            serg Sergei Golubchik made changes -
            Fix Version/s 11.2.1 [ 29034 ]
            Fix Version/s 10.5 [ 23123 ]
            Fix Version/s 10.6 [ 24028 ]
            Fix Version/s 10.11 [ 27614 ]
            Resolution Fixed [ 1 ]
            Status Confirmed [ 10101 ] Closed [ 6 ]

            People

              shulga Dmitry Shulga
              elenst Elena Stepanova
              Votes:
              2 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.