Fix for BUG#19725 "Calls to SF in other database are not replicated
correctly in some cases". In short, calls to a stored function located in another database than the default database, may fail to replicate if the call was made by SET, SELECT, or DO. Longer: when a stored function is called from a statement which does not go to binlog ("SET @A=somedb.myfunc()", "SELECT somedb.myfunc()", "DO somedb.myfunc()"), this crafted statement is binlogged: "SELECT myfunc();" (accompanied with a mention of the default database if there is one). So, if "somedb" is not the default database, the slave would fail to find myfunc(). The fix is to specify the function's database name in the crafted binlogged statement, like this: "SELECT somedb.myfunc();". Test added in rpl_sp.test. mysql-test/r/rpl_sp.result: Because I moved the SHOW BINLOG EVENTS down a bit, big portions of its output move. Also, the function's database name appears in SELECT statements. mysql-test/t/rpl_sp.test: Adding test for BUG#19725. Moving the SHOW BINLOG EVENTS down, it is run at the very end to test everything. sql/sp_head.cc: When binlogging a "SELECT myfunc()" (when a stored function is executed inside a statement which does not go to the binlog (like a SET, SELECT, DO), we need to write "SELECT db_of_myfunc().myfunc()", because the function may be in a database which is not the default database.
Showing
Please register or sign in to comment