Hi, Sanja! On Feb 25, sanja@mariadb.com wrote:

revision-id: 60c1dc1ab24bfe9b3f4a898fe5e7cb070ee02cf7 parent(s): d0d6284cab70af148269d95744f615454cac24bb committer: Oleksandr Byelkin branch nick: work-maria-10.1-MDEV-6997-real timestamp: 2015-02-25 19:00:57 +0100 message:

MDEV-6997: SET STATEMENT last_insert_id FOR ... does not affect the value written to the binlog

Problem was in reinitialization of first_successful_insert_id_in_prev_stmt_for_binlog after setting variables.

diff --git a/sql/sql_parse.cc b/sql/sql_parse.cc index 5af700b..54abfd0 100644 --- a/sql/sql_parse.cc +++ b/sql/sql_parse.cc @@ -2728,6 +2728,10 @@ static bool do_execute_sp(THD *thd, sp_head *sp) my_error(ER_WRONG_ARGUMENTS, MYF(0), "SET"); goto error; } + if (!thd->in_sub_stmt) /* stored functions and triggers are a special case */ + { + thd->stmt_depends_on_first_successful_insert_id_in_prev_stmt= 0; + } }

This seems to be a pretty complicated matter, and your comment isn't very helpful. Try this: The value of last_insert_id is remembered in THD to be written to binlog when it's used *the first time* in the statement. But SET STATEMENT must read the old value of last_insert_id to be able to restore it at the end. This should not count at "reading of last_insert_id" and should not remember last_insert_id for binlog. That is, it should set stmt_depends_on_first_successful_insert_id_in_prev_stmt flag. And try the test case where SET STATEMENT last_insert_id is used inside a trigger or a stored function. I don't think you handle this case correctly. Try both cases, when stmt_depends... is 0 and is 1 at the point of this if(). I suspect you should not set stmt_depends_on_first_successful_insert_id_in_prev_stmt to 0, but you need to make sure it didn't change. That is, you need to set it to its old value (which may or may not be 0). Regards, Sergei