<?xml version="1.0" encoding="utf-8"?>
<launchpad-bug id="948583">
  <date_last_updated>2012-03-12 22:46:32.470775+00:00</date_last_updated>
  <api_links>
    <bug_api_link>https://api.launchpad.net/1.0/bugs/948583</bug_api_link>
    <bug_owner_link>https://api.launchpad.net/1.0/~elenst</bug_owner_link>
    <milestone_link>https://api.launchpad.net/1.0/maria/+milestone/5.1</milestone_link>
    <linked_branches_collection_link>https://api.launchpad.net/1.0/bugs/948583/linked_branches</linked_branches_collection_link>
    <activity_link>https://api.launchpad.net/1.0/bugs/948583/activity</activity_link>
  </api_links>
  <bug_web_link>https://bugs.launchpad.net/bugs/948583</bug_web_link>
  <owner>Elena Stepanova</owner>
  <assignee></assignee>
  <milestone_title>Maria 5.1</milestone_title>
  <duplicate_link></duplicate_link>
  <duplicate_bug_id></duplicate_bug_id>
  <title>Stored procedure doesn't not take into account ALTER TABLE, causes wrong result or replication abort</title>
  <status>New</status>
  <importance>Medium</importance>
  <created>2012-03-07 00:04:42.862847+00:00</created>
  <description>
<![CDATA[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]]>  </description>
  <activities>
    <activity datechanged="2012-03-07T00:04:42.862847+00:00">
      <oldvalue>
<![CDATA[]]>      </oldvalue>
      <newvalue>
<![CDATA[]]>      </newvalue>
      <whatchanged>bug</whatchanged>
      <person>Elena Stepanova</person>
      <message>added bug</message>
    </activity>
    <activity datechanged="2012-03-12T22:46:32.068891+00:00">
      <oldvalue>
<![CDATA[]]>      </oldvalue>
      <newvalue>
<![CDATA[upstream]]>      </newvalue>
      <whatchanged>tags</whatchanged>
      <person>Elena Stepanova</person>
      <message></message>
    </activity>
  </activities>
</launchpad-bug>
