Approximative fixes for BUG#2610,2611,9100 i.e. WL#2146 binlogging/replication of routines (stored procs and functions).
Approximative, because it's using our binlogging way (what we call "query"-level) and this is not as good as record-level binlog (5.1) would be. It imposes several
limitations to routines, and has caveats (which I'll document, and for which the server will try to issue errors but that is not always possible).
Reason I don't propagate caller info to the binlog as planned is that on master and slave
users may be different; even with that some caveats would remain.
mysql-test/mysql-test-run.sh:
In the testsuite we know what we do, we are not creating nasty routines, and breaking binlog is ok except in rpl_sp.
mysql-test/r/blackhole.result:
Updating results now that 4.1 has been merged
mysql-test/valgrind.supp:
Some suppressions for Valgrind (useful on my machine Suse 9.1);
this is just adding to the already existing suppressions of pthread and dl.
sql/item_func.cc:
Don't binlog the substatements when executing a function. If the function
is declared to modify data and does not complete, warning "broken binlog".
Note that SELECT myfunc() will not be binlogged even if myfunc() updates data (will be documented);
but INSERT INTO t VALUES(myfunc()) will be binlogged (what decides is if the caller
gets binlogged; the function changes nothing to binlogging).
sql/log_event.cc:
Just making functions which can be re-used when we binlog more strings
in status_vars in Query_log_event (e.g. one day "user", "host").
sql/log_event.h:
comment
sql/mysql_priv.h:
--log-bin-trust-routine-creators
sql/mysqld.cc:
--log-bin-trust-routine-creators
sql/set_var.cc:
--log-bin-trust-routine-creators
sql/share/errmsg.txt:
error messages to warn about problems with routines and binlog
sql/slave.cc:
If in a routine, replication table inclusion/exclusion rules always answer "replicate!" (see comment in code).
sql/sp.cc:
If binlog is on: errors if one wants to create a non-deterministic update routine
(repeatability problem - note that the test is not perfect for functions) or does not have SUPER (because routines can easily
be made to destroy slave's data with just CREATE ROUTINE and EXECUTE priv on master).
--log-bin-trust-routine-creators removes these errors.
Binlogging of CREATE PROCEDURE|FUNCTION.
sql/sql_acl.cc:
No thd==0 in tables_ok().
sql/sql_parse.cc:
Binlogging of CALL (and not of the substatements of the SP).
If SP returns error, we don't binlog it (see comment); we push warning in this case.
Binlogging of ALTER|DROP PROCEDURE|FUNCTION with safety messages.
2005-05-05 14:20:53 +02:00
stop slave;
drop table if exists t1,t2,t3,t4,t5,t6,t7,t8,t9;
reset master;
reset slave;
drop table if exists t1,t2,t3,t4,t5,t6,t7,t8,t9;
start slave;
2005-11-10 17:50:51 +01:00
drop database if exists mysqltest1;
create database mysqltest1;
Approximative fixes for BUG#2610,2611,9100 i.e. WL#2146 binlogging/replication of routines (stored procs and functions).
Approximative, because it's using our binlogging way (what we call "query"-level) and this is not as good as record-level binlog (5.1) would be. It imposes several
limitations to routines, and has caveats (which I'll document, and for which the server will try to issue errors but that is not always possible).
Reason I don't propagate caller info to the binlog as planned is that on master and slave
users may be different; even with that some caveats would remain.
mysql-test/mysql-test-run.sh:
In the testsuite we know what we do, we are not creating nasty routines, and breaking binlog is ok except in rpl_sp.
mysql-test/r/blackhole.result:
Updating results now that 4.1 has been merged
mysql-test/valgrind.supp:
Some suppressions for Valgrind (useful on my machine Suse 9.1);
this is just adding to the already existing suppressions of pthread and dl.
sql/item_func.cc:
Don't binlog the substatements when executing a function. If the function
is declared to modify data and does not complete, warning "broken binlog".
Note that SELECT myfunc() will not be binlogged even if myfunc() updates data (will be documented);
but INSERT INTO t VALUES(myfunc()) will be binlogged (what decides is if the caller
gets binlogged; the function changes nothing to binlogging).
sql/log_event.cc:
Just making functions which can be re-used when we binlog more strings
in status_vars in Query_log_event (e.g. one day "user", "host").
sql/log_event.h:
comment
sql/mysql_priv.h:
--log-bin-trust-routine-creators
sql/mysqld.cc:
--log-bin-trust-routine-creators
sql/set_var.cc:
--log-bin-trust-routine-creators
sql/share/errmsg.txt:
error messages to warn about problems with routines and binlog
sql/slave.cc:
If in a routine, replication table inclusion/exclusion rules always answer "replicate!" (see comment in code).
sql/sp.cc:
If binlog is on: errors if one wants to create a non-deterministic update routine
(repeatability problem - note that the test is not perfect for functions) or does not have SUPER (because routines can easily
be made to destroy slave's data with just CREATE ROUTINE and EXECUTE priv on master).
--log-bin-trust-routine-creators removes these errors.
Binlogging of CREATE PROCEDURE|FUNCTION.
sql/sql_acl.cc:
No thd==0 in tables_ok().
sql/sql_parse.cc:
Binlogging of CALL (and not of the substatements of the SP).
If SP returns error, we don't binlog it (see comment); we push warning in this case.
Binlogging of ALTER|DROP PROCEDURE|FUNCTION with safety messages.
2005-05-05 14:20:53 +02:00
use mysqltest1;
create table t1 (a varchar(100));
use mysqltest1;
create procedure foo()
begin
declare b int;
set b = 8;
insert into t1 values (b);
insert into t1 values (unix_timestamp());
end|
select * from mysql.proc where name='foo' and db='mysqltest1';
db name type specific_name language sql_data_access is_deterministic security_type param_list returns body definer created modified sql_mode comment
2005-11-10 17:50:51 +01:00
mysqltest1 foo PROCEDURE foo SQL CONTAINS_SQL NO DEFINER begin
Approximative fixes for BUG#2610,2611,9100 i.e. WL#2146 binlogging/replication of routines (stored procs and functions).
Approximative, because it's using our binlogging way (what we call "query"-level) and this is not as good as record-level binlog (5.1) would be. It imposes several
limitations to routines, and has caveats (which I'll document, and for which the server will try to issue errors but that is not always possible).
Reason I don't propagate caller info to the binlog as planned is that on master and slave
users may be different; even with that some caveats would remain.
mysql-test/mysql-test-run.sh:
In the testsuite we know what we do, we are not creating nasty routines, and breaking binlog is ok except in rpl_sp.
mysql-test/r/blackhole.result:
Updating results now that 4.1 has been merged
mysql-test/valgrind.supp:
Some suppressions for Valgrind (useful on my machine Suse 9.1);
this is just adding to the already existing suppressions of pthread and dl.
sql/item_func.cc:
Don't binlog the substatements when executing a function. If the function
is declared to modify data and does not complete, warning "broken binlog".
Note that SELECT myfunc() will not be binlogged even if myfunc() updates data (will be documented);
but INSERT INTO t VALUES(myfunc()) will be binlogged (what decides is if the caller
gets binlogged; the function changes nothing to binlogging).
sql/log_event.cc:
Just making functions which can be re-used when we binlog more strings
in status_vars in Query_log_event (e.g. one day "user", "host").
sql/log_event.h:
comment
sql/mysql_priv.h:
--log-bin-trust-routine-creators
sql/mysqld.cc:
--log-bin-trust-routine-creators
sql/set_var.cc:
--log-bin-trust-routine-creators
sql/share/errmsg.txt:
error messages to warn about problems with routines and binlog
sql/slave.cc:
If in a routine, replication table inclusion/exclusion rules always answer "replicate!" (see comment in code).
sql/sp.cc:
If binlog is on: errors if one wants to create a non-deterministic update routine
(repeatability problem - note that the test is not perfect for functions) or does not have SUPER (because routines can easily
be made to destroy slave's data with just CREATE ROUTINE and EXECUTE priv on master).
--log-bin-trust-routine-creators removes these errors.
Binlogging of CREATE PROCEDURE|FUNCTION.
sql/sql_acl.cc:
No thd==0 in tables_ok().
sql/sql_parse.cc:
Binlogging of CALL (and not of the substatements of the SP).
If SP returns error, we don't binlog it (see comment); we push warning in this case.
Binlogging of ALTER|DROP PROCEDURE|FUNCTION with safety messages.
2005-05-05 14:20:53 +02:00
declare b int;
set b = 8;
insert into t1 values (b);
insert into t1 values (unix_timestamp());
end root@localhost # #
select * from mysql.proc where name='foo' and db='mysqltest1';
db name type specific_name language sql_data_access is_deterministic security_type param_list returns body definer created modified sql_mode comment
2005-11-10 17:50:51 +01:00
mysqltest1 foo PROCEDURE foo SQL CONTAINS_SQL NO DEFINER begin
Approximative fixes for BUG#2610,2611,9100 i.e. WL#2146 binlogging/replication of routines (stored procs and functions).
Approximative, because it's using our binlogging way (what we call "query"-level) and this is not as good as record-level binlog (5.1) would be. It imposes several
limitations to routines, and has caveats (which I'll document, and for which the server will try to issue errors but that is not always possible).
Reason I don't propagate caller info to the binlog as planned is that on master and slave
users may be different; even with that some caveats would remain.
mysql-test/mysql-test-run.sh:
In the testsuite we know what we do, we are not creating nasty routines, and breaking binlog is ok except in rpl_sp.
mysql-test/r/blackhole.result:
Updating results now that 4.1 has been merged
mysql-test/valgrind.supp:
Some suppressions for Valgrind (useful on my machine Suse 9.1);
this is just adding to the already existing suppressions of pthread and dl.
sql/item_func.cc:
Don't binlog the substatements when executing a function. If the function
is declared to modify data and does not complete, warning "broken binlog".
Note that SELECT myfunc() will not be binlogged even if myfunc() updates data (will be documented);
but INSERT INTO t VALUES(myfunc()) will be binlogged (what decides is if the caller
gets binlogged; the function changes nothing to binlogging).
sql/log_event.cc:
Just making functions which can be re-used when we binlog more strings
in status_vars in Query_log_event (e.g. one day "user", "host").
sql/log_event.h:
comment
sql/mysql_priv.h:
--log-bin-trust-routine-creators
sql/mysqld.cc:
--log-bin-trust-routine-creators
sql/set_var.cc:
--log-bin-trust-routine-creators
sql/share/errmsg.txt:
error messages to warn about problems with routines and binlog
sql/slave.cc:
If in a routine, replication table inclusion/exclusion rules always answer "replicate!" (see comment in code).
sql/sp.cc:
If binlog is on: errors if one wants to create a non-deterministic update routine
(repeatability problem - note that the test is not perfect for functions) or does not have SUPER (because routines can easily
be made to destroy slave's data with just CREATE ROUTINE and EXECUTE priv on master).
--log-bin-trust-routine-creators removes these errors.
Binlogging of CREATE PROCEDURE|FUNCTION.
sql/sql_acl.cc:
No thd==0 in tables_ok().
sql/sql_parse.cc:
Binlogging of CALL (and not of the substatements of the SP).
If SP returns error, we don't binlog it (see comment); we push warning in this case.
Binlogging of ALTER|DROP PROCEDURE|FUNCTION with safety messages.
2005-05-05 14:20:53 +02:00
declare b int;
set b = 8;
insert into t1 values (b);
insert into t1 values (unix_timestamp());
2006-03-02 13:18:49 +01:00
end root@localhost # #
Approximative fixes for BUG#2610,2611,9100 i.e. WL#2146 binlogging/replication of routines (stored procs and functions).
Approximative, because it's using our binlogging way (what we call "query"-level) and this is not as good as record-level binlog (5.1) would be. It imposes several
limitations to routines, and has caveats (which I'll document, and for which the server will try to issue errors but that is not always possible).
Reason I don't propagate caller info to the binlog as planned is that on master and slave
users may be different; even with that some caveats would remain.
mysql-test/mysql-test-run.sh:
In the testsuite we know what we do, we are not creating nasty routines, and breaking binlog is ok except in rpl_sp.
mysql-test/r/blackhole.result:
Updating results now that 4.1 has been merged
mysql-test/valgrind.supp:
Some suppressions for Valgrind (useful on my machine Suse 9.1);
this is just adding to the already existing suppressions of pthread and dl.
sql/item_func.cc:
Don't binlog the substatements when executing a function. If the function
is declared to modify data and does not complete, warning "broken binlog".
Note that SELECT myfunc() will not be binlogged even if myfunc() updates data (will be documented);
but INSERT INTO t VALUES(myfunc()) will be binlogged (what decides is if the caller
gets binlogged; the function changes nothing to binlogging).
sql/log_event.cc:
Just making functions which can be re-used when we binlog more strings
in status_vars in Query_log_event (e.g. one day "user", "host").
sql/log_event.h:
comment
sql/mysql_priv.h:
--log-bin-trust-routine-creators
sql/mysqld.cc:
--log-bin-trust-routine-creators
sql/set_var.cc:
--log-bin-trust-routine-creators
sql/share/errmsg.txt:
error messages to warn about problems with routines and binlog
sql/slave.cc:
If in a routine, replication table inclusion/exclusion rules always answer "replicate!" (see comment in code).
sql/sp.cc:
If binlog is on: errors if one wants to create a non-deterministic update routine
(repeatability problem - note that the test is not perfect for functions) or does not have SUPER (because routines can easily
be made to destroy slave's data with just CREATE ROUTINE and EXECUTE priv on master).
--log-bin-trust-routine-creators removes these errors.
Binlogging of CREATE PROCEDURE|FUNCTION.
sql/sql_acl.cc:
No thd==0 in tables_ok().
sql/sql_parse.cc:
Binlogging of CALL (and not of the substatements of the SP).
If SP returns error, we don't binlog it (see comment); we push warning in this case.
Binlogging of ALTER|DROP PROCEDURE|FUNCTION with safety messages.
2005-05-05 14:20:53 +02:00
set timestamp=1000000000;
call foo();
select * from t1;
a
8
1000000000
select * from t1;
a
8
1000000000
delete from t1;
create procedure foo2()
select * from mysqltest1.t1;
call foo2();
a
alter procedure foo2 contains sql;
drop table t1;
create table t1 (a int);
create table t2 like t1;
create procedure foo3()
deterministic
insert into t1 values (15);
grant CREATE ROUTINE, EXECUTE on mysqltest1.* to "zedjzlcsjhd"@127.0.0.1;
grant SELECT on mysqltest1.t1 to "zedjzlcsjhd"@127.0.0.1;
grant SELECT, INSERT on mysqltest1.t2 to "zedjzlcsjhd"@127.0.0.1;
2006-01-04 15:25:32 +01:00
SELECT 1;
1
1
Approximative fixes for BUG#2610,2611,9100 i.e. WL#2146 binlogging/replication of routines (stored procs and functions).
Approximative, because it's using our binlogging way (what we call "query"-level) and this is not as good as record-level binlog (5.1) would be. It imposes several
limitations to routines, and has caveats (which I'll document, and for which the server will try to issue errors but that is not always possible).
Reason I don't propagate caller info to the binlog as planned is that on master and slave
users may be different; even with that some caveats would remain.
mysql-test/mysql-test-run.sh:
In the testsuite we know what we do, we are not creating nasty routines, and breaking binlog is ok except in rpl_sp.
mysql-test/r/blackhole.result:
Updating results now that 4.1 has been merged
mysql-test/valgrind.supp:
Some suppressions for Valgrind (useful on my machine Suse 9.1);
this is just adding to the already existing suppressions of pthread and dl.
sql/item_func.cc:
Don't binlog the substatements when executing a function. If the function
is declared to modify data and does not complete, warning "broken binlog".
Note that SELECT myfunc() will not be binlogged even if myfunc() updates data (will be documented);
but INSERT INTO t VALUES(myfunc()) will be binlogged (what decides is if the caller
gets binlogged; the function changes nothing to binlogging).
sql/log_event.cc:
Just making functions which can be re-used when we binlog more strings
in status_vars in Query_log_event (e.g. one day "user", "host").
sql/log_event.h:
comment
sql/mysql_priv.h:
--log-bin-trust-routine-creators
sql/mysqld.cc:
--log-bin-trust-routine-creators
sql/set_var.cc:
--log-bin-trust-routine-creators
sql/share/errmsg.txt:
error messages to warn about problems with routines and binlog
sql/slave.cc:
If in a routine, replication table inclusion/exclusion rules always answer "replicate!" (see comment in code).
sql/sp.cc:
If binlog is on: errors if one wants to create a non-deterministic update routine
(repeatability problem - note that the test is not perfect for functions) or does not have SUPER (because routines can easily
be made to destroy slave's data with just CREATE ROUTINE and EXECUTE priv on master).
--log-bin-trust-routine-creators removes these errors.
Binlogging of CREATE PROCEDURE|FUNCTION.
sql/sql_acl.cc:
No thd==0 in tables_ok().
sql/sql_parse.cc:
Binlogging of CALL (and not of the substatements of the SP).
If SP returns error, we don't binlog it (see comment); we push warning in this case.
Binlogging of ALTER|DROP PROCEDURE|FUNCTION with safety messages.
2005-05-05 14:20:53 +02:00
create procedure foo4()
deterministic
begin
insert into t2 values(3);
insert into t1 values (5);
end|
call foo4();
2005-05-05 18:28:54 +02:00
Got one of the listed errors
Approximative fixes for BUG#2610,2611,9100 i.e. WL#2146 binlogging/replication of routines (stored procs and functions).
Approximative, because it's using our binlogging way (what we call "query"-level) and this is not as good as record-level binlog (5.1) would be. It imposes several
limitations to routines, and has caveats (which I'll document, and for which the server will try to issue errors but that is not always possible).
Reason I don't propagate caller info to the binlog as planned is that on master and slave
users may be different; even with that some caveats would remain.
mysql-test/mysql-test-run.sh:
In the testsuite we know what we do, we are not creating nasty routines, and breaking binlog is ok except in rpl_sp.
mysql-test/r/blackhole.result:
Updating results now that 4.1 has been merged
mysql-test/valgrind.supp:
Some suppressions for Valgrind (useful on my machine Suse 9.1);
this is just adding to the already existing suppressions of pthread and dl.
sql/item_func.cc:
Don't binlog the substatements when executing a function. If the function
is declared to modify data and does not complete, warning "broken binlog".
Note that SELECT myfunc() will not be binlogged even if myfunc() updates data (will be documented);
but INSERT INTO t VALUES(myfunc()) will be binlogged (what decides is if the caller
gets binlogged; the function changes nothing to binlogging).
sql/log_event.cc:
Just making functions which can be re-used when we binlog more strings
in status_vars in Query_log_event (e.g. one day "user", "host").
sql/log_event.h:
comment
sql/mysql_priv.h:
--log-bin-trust-routine-creators
sql/mysqld.cc:
--log-bin-trust-routine-creators
sql/set_var.cc:
--log-bin-trust-routine-creators
sql/share/errmsg.txt:
error messages to warn about problems with routines and binlog
sql/slave.cc:
If in a routine, replication table inclusion/exclusion rules always answer "replicate!" (see comment in code).
sql/sp.cc:
If binlog is on: errors if one wants to create a non-deterministic update routine
(repeatability problem - note that the test is not perfect for functions) or does not have SUPER (because routines can easily
be made to destroy slave's data with just CREATE ROUTINE and EXECUTE priv on master).
--log-bin-trust-routine-creators removes these errors.
Binlogging of CREATE PROCEDURE|FUNCTION.
sql/sql_acl.cc:
No thd==0 in tables_ok().
sql/sql_parse.cc:
Binlogging of CALL (and not of the substatements of the SP).
If SP returns error, we don't binlog it (see comment); we push warning in this case.
Binlogging of ALTER|DROP PROCEDURE|FUNCTION with safety messages.
2005-05-05 14:20:53 +02:00
call foo3();
show warnings;
Level Code Message
call foo4();
2005-05-05 18:28:54 +02:00
Got one of the listed errors
Approximative fixes for BUG#2610,2611,9100 i.e. WL#2146 binlogging/replication of routines (stored procs and functions).
Approximative, because it's using our binlogging way (what we call "query"-level) and this is not as good as record-level binlog (5.1) would be. It imposes several
limitations to routines, and has caveats (which I'll document, and for which the server will try to issue errors but that is not always possible).
Reason I don't propagate caller info to the binlog as planned is that on master and slave
users may be different; even with that some caveats would remain.
mysql-test/mysql-test-run.sh:
In the testsuite we know what we do, we are not creating nasty routines, and breaking binlog is ok except in rpl_sp.
mysql-test/r/blackhole.result:
Updating results now that 4.1 has been merged
mysql-test/valgrind.supp:
Some suppressions for Valgrind (useful on my machine Suse 9.1);
this is just adding to the already existing suppressions of pthread and dl.
sql/item_func.cc:
Don't binlog the substatements when executing a function. If the function
is declared to modify data and does not complete, warning "broken binlog".
Note that SELECT myfunc() will not be binlogged even if myfunc() updates data (will be documented);
but INSERT INTO t VALUES(myfunc()) will be binlogged (what decides is if the caller
gets binlogged; the function changes nothing to binlogging).
sql/log_event.cc:
Just making functions which can be re-used when we binlog more strings
in status_vars in Query_log_event (e.g. one day "user", "host").
sql/log_event.h:
comment
sql/mysql_priv.h:
--log-bin-trust-routine-creators
sql/mysqld.cc:
--log-bin-trust-routine-creators
sql/set_var.cc:
--log-bin-trust-routine-creators
sql/share/errmsg.txt:
error messages to warn about problems with routines and binlog
sql/slave.cc:
If in a routine, replication table inclusion/exclusion rules always answer "replicate!" (see comment in code).
sql/sp.cc:
If binlog is on: errors if one wants to create a non-deterministic update routine
(repeatability problem - note that the test is not perfect for functions) or does not have SUPER (because routines can easily
be made to destroy slave's data with just CREATE ROUTINE and EXECUTE priv on master).
--log-bin-trust-routine-creators removes these errors.
Binlogging of CREATE PROCEDURE|FUNCTION.
sql/sql_acl.cc:
No thd==0 in tables_ok().
sql/sql_parse.cc:
Binlogging of CALL (and not of the substatements of the SP).
If SP returns error, we don't binlog it (see comment); we push warning in this case.
Binlogging of ALTER|DROP PROCEDURE|FUNCTION with safety messages.
2005-05-05 14:20:53 +02:00
alter procedure foo4 sql security invoker;
call foo4();
show warnings;
Level Code Message
select * from t1;
a
15
5
select * from t2;
a
3
3
3
select * from t1;
a
15
5
select * from t2;
a
3
2005-08-25 15:34:34 +02:00
3
3
2005-11-10 17:50:51 +01:00
delete from t2;
alter table t2 add unique (a);
drop procedure foo4;
create procedure foo4()
deterministic
begin
insert into t2 values(20),(20);
end|
call foo4();
ERROR 23000: Duplicate entry '20' for key 1
show warnings;
Level Code Message
Error 1062 Duplicate entry '20' for key 1
select * from t2;
a
20
select * from t2;
a
20
Approximative fixes for BUG#2610,2611,9100 i.e. WL#2146 binlogging/replication of routines (stored procs and functions).
Approximative, because it's using our binlogging way (what we call "query"-level) and this is not as good as record-level binlog (5.1) would be. It imposes several
limitations to routines, and has caveats (which I'll document, and for which the server will try to issue errors but that is not always possible).
Reason I don't propagate caller info to the binlog as planned is that on master and slave
users may be different; even with that some caveats would remain.
mysql-test/mysql-test-run.sh:
In the testsuite we know what we do, we are not creating nasty routines, and breaking binlog is ok except in rpl_sp.
mysql-test/r/blackhole.result:
Updating results now that 4.1 has been merged
mysql-test/valgrind.supp:
Some suppressions for Valgrind (useful on my machine Suse 9.1);
this is just adding to the already existing suppressions of pthread and dl.
sql/item_func.cc:
Don't binlog the substatements when executing a function. If the function
is declared to modify data and does not complete, warning "broken binlog".
Note that SELECT myfunc() will not be binlogged even if myfunc() updates data (will be documented);
but INSERT INTO t VALUES(myfunc()) will be binlogged (what decides is if the caller
gets binlogged; the function changes nothing to binlogging).
sql/log_event.cc:
Just making functions which can be re-used when we binlog more strings
in status_vars in Query_log_event (e.g. one day "user", "host").
sql/log_event.h:
comment
sql/mysql_priv.h:
--log-bin-trust-routine-creators
sql/mysqld.cc:
--log-bin-trust-routine-creators
sql/set_var.cc:
--log-bin-trust-routine-creators
sql/share/errmsg.txt:
error messages to warn about problems with routines and binlog
sql/slave.cc:
If in a routine, replication table inclusion/exclusion rules always answer "replicate!" (see comment in code).
sql/sp.cc:
If binlog is on: errors if one wants to create a non-deterministic update routine
(repeatability problem - note that the test is not perfect for functions) or does not have SUPER (because routines can easily
be made to destroy slave's data with just CREATE ROUTINE and EXECUTE priv on master).
--log-bin-trust-routine-creators removes these errors.
Binlogging of CREATE PROCEDURE|FUNCTION.
sql/sql_acl.cc:
No thd==0 in tables_ok().
sql/sql_parse.cc:
Binlogging of CALL (and not of the substatements of the SP).
If SP returns error, we don't binlog it (see comment); we push warning in this case.
Binlogging of ALTER|DROP PROCEDURE|FUNCTION with safety messages.
2005-05-05 14:20:53 +02:00
select * from mysql.proc where name="foo4" and db='mysqltest1';
db name type specific_name language sql_data_access is_deterministic security_type param_list returns body definer created modified sql_mode comment
2005-11-10 17:50:51 +01:00
mysqltest1 foo4 PROCEDURE foo4 SQL CONTAINS_SQL YES DEFINER begin
insert into t2 values(20),(20);
2006-03-02 13:18:49 +01:00
end root@localhost # #
Approximative fixes for BUG#2610,2611,9100 i.e. WL#2146 binlogging/replication of routines (stored procs and functions).
Approximative, because it's using our binlogging way (what we call "query"-level) and this is not as good as record-level binlog (5.1) would be. It imposes several
limitations to routines, and has caveats (which I'll document, and for which the server will try to issue errors but that is not always possible).
Reason I don't propagate caller info to the binlog as planned is that on master and slave
users may be different; even with that some caveats would remain.
mysql-test/mysql-test-run.sh:
In the testsuite we know what we do, we are not creating nasty routines, and breaking binlog is ok except in rpl_sp.
mysql-test/r/blackhole.result:
Updating results now that 4.1 has been merged
mysql-test/valgrind.supp:
Some suppressions for Valgrind (useful on my machine Suse 9.1);
this is just adding to the already existing suppressions of pthread and dl.
sql/item_func.cc:
Don't binlog the substatements when executing a function. If the function
is declared to modify data and does not complete, warning "broken binlog".
Note that SELECT myfunc() will not be binlogged even if myfunc() updates data (will be documented);
but INSERT INTO t VALUES(myfunc()) will be binlogged (what decides is if the caller
gets binlogged; the function changes nothing to binlogging).
sql/log_event.cc:
Just making functions which can be re-used when we binlog more strings
in status_vars in Query_log_event (e.g. one day "user", "host").
sql/log_event.h:
comment
sql/mysql_priv.h:
--log-bin-trust-routine-creators
sql/mysqld.cc:
--log-bin-trust-routine-creators
sql/set_var.cc:
--log-bin-trust-routine-creators
sql/share/errmsg.txt:
error messages to warn about problems with routines and binlog
sql/slave.cc:
If in a routine, replication table inclusion/exclusion rules always answer "replicate!" (see comment in code).
sql/sp.cc:
If binlog is on: errors if one wants to create a non-deterministic update routine
(repeatability problem - note that the test is not perfect for functions) or does not have SUPER (because routines can easily
be made to destroy slave's data with just CREATE ROUTINE and EXECUTE priv on master).
--log-bin-trust-routine-creators removes these errors.
Binlogging of CREATE PROCEDURE|FUNCTION.
sql/sql_acl.cc:
No thd==0 in tables_ok().
sql/sql_parse.cc:
Binlogging of CALL (and not of the substatements of the SP).
If SP returns error, we don't binlog it (see comment); we push warning in this case.
Binlogging of ALTER|DROP PROCEDURE|FUNCTION with safety messages.
2005-05-05 14:20:53 +02:00
drop procedure foo4;
select * from mysql.proc where name="foo4" and db='mysqltest1';
db name type specific_name language sql_data_access is_deterministic security_type param_list returns body definer created modified sql_mode comment
select * from mysql.proc where name="foo4" and db='mysqltest1';
db name type specific_name language sql_data_access is_deterministic security_type param_list returns body definer created modified sql_mode comment
drop procedure foo;
drop procedure foo2;
drop procedure foo3;
create function fn1(x int)
returns int
2005-11-10 17:50:51 +01:00
begin
insert into t1 values (x);
return x+2;
end|
ERROR HY000: This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA in its declaration and binary logging is enabled (you *might* want to use the less safe log_bin_trust_function_creators variable)
create function fn1(x int)
returns int
Approximative fixes for BUG#2610,2611,9100 i.e. WL#2146 binlogging/replication of routines (stored procs and functions).
Approximative, because it's using our binlogging way (what we call "query"-level) and this is not as good as record-level binlog (5.1) would be. It imposes several
limitations to routines, and has caveats (which I'll document, and for which the server will try to issue errors but that is not always possible).
Reason I don't propagate caller info to the binlog as planned is that on master and slave
users may be different; even with that some caveats would remain.
mysql-test/mysql-test-run.sh:
In the testsuite we know what we do, we are not creating nasty routines, and breaking binlog is ok except in rpl_sp.
mysql-test/r/blackhole.result:
Updating results now that 4.1 has been merged
mysql-test/valgrind.supp:
Some suppressions for Valgrind (useful on my machine Suse 9.1);
this is just adding to the already existing suppressions of pthread and dl.
sql/item_func.cc:
Don't binlog the substatements when executing a function. If the function
is declared to modify data and does not complete, warning "broken binlog".
Note that SELECT myfunc() will not be binlogged even if myfunc() updates data (will be documented);
but INSERT INTO t VALUES(myfunc()) will be binlogged (what decides is if the caller
gets binlogged; the function changes nothing to binlogging).
sql/log_event.cc:
Just making functions which can be re-used when we binlog more strings
in status_vars in Query_log_event (e.g. one day "user", "host").
sql/log_event.h:
comment
sql/mysql_priv.h:
--log-bin-trust-routine-creators
sql/mysqld.cc:
--log-bin-trust-routine-creators
sql/set_var.cc:
--log-bin-trust-routine-creators
sql/share/errmsg.txt:
error messages to warn about problems with routines and binlog
sql/slave.cc:
If in a routine, replication table inclusion/exclusion rules always answer "replicate!" (see comment in code).
sql/sp.cc:
If binlog is on: errors if one wants to create a non-deterministic update routine
(repeatability problem - note that the test is not perfect for functions) or does not have SUPER (because routines can easily
be made to destroy slave's data with just CREATE ROUTINE and EXECUTE priv on master).
--log-bin-trust-routine-creators removes these errors.
Binlogging of CREATE PROCEDURE|FUNCTION.
sql/sql_acl.cc:
No thd==0 in tables_ok().
sql/sql_parse.cc:
Binlogging of CALL (and not of the substatements of the SP).
If SP returns error, we don't binlog it (see comment); we push warning in this case.
Binlogging of ALTER|DROP PROCEDURE|FUNCTION with safety messages.
2005-05-05 14:20:53 +02:00
deterministic
begin
insert into t1 values (x);
return x+2;
end|
delete t1,t2 from t1,t2;
select fn1(20);
fn1(20)
22
insert into t2 values(fn1(21));
select * from t1;
a
21
20
select * from t2;
a
23
select * from t1;
a
21
2005-08-25 15:34:34 +02:00
20
Approximative fixes for BUG#2610,2611,9100 i.e. WL#2146 binlogging/replication of routines (stored procs and functions).
Approximative, because it's using our binlogging way (what we call "query"-level) and this is not as good as record-level binlog (5.1) would be. It imposes several
limitations to routines, and has caveats (which I'll document, and for which the server will try to issue errors but that is not always possible).
Reason I don't propagate caller info to the binlog as planned is that on master and slave
users may be different; even with that some caveats would remain.
mysql-test/mysql-test-run.sh:
In the testsuite we know what we do, we are not creating nasty routines, and breaking binlog is ok except in rpl_sp.
mysql-test/r/blackhole.result:
Updating results now that 4.1 has been merged
mysql-test/valgrind.supp:
Some suppressions for Valgrind (useful on my machine Suse 9.1);
this is just adding to the already existing suppressions of pthread and dl.
sql/item_func.cc:
Don't binlog the substatements when executing a function. If the function
is declared to modify data and does not complete, warning "broken binlog".
Note that SELECT myfunc() will not be binlogged even if myfunc() updates data (will be documented);
but INSERT INTO t VALUES(myfunc()) will be binlogged (what decides is if the caller
gets binlogged; the function changes nothing to binlogging).
sql/log_event.cc:
Just making functions which can be re-used when we binlog more strings
in status_vars in Query_log_event (e.g. one day "user", "host").
sql/log_event.h:
comment
sql/mysql_priv.h:
--log-bin-trust-routine-creators
sql/mysqld.cc:
--log-bin-trust-routine-creators
sql/set_var.cc:
--log-bin-trust-routine-creators
sql/share/errmsg.txt:
error messages to warn about problems with routines and binlog
sql/slave.cc:
If in a routine, replication table inclusion/exclusion rules always answer "replicate!" (see comment in code).
sql/sp.cc:
If binlog is on: errors if one wants to create a non-deterministic update routine
(repeatability problem - note that the test is not perfect for functions) or does not have SUPER (because routines can easily
be made to destroy slave's data with just CREATE ROUTINE and EXECUTE priv on master).
--log-bin-trust-routine-creators removes these errors.
Binlogging of CREATE PROCEDURE|FUNCTION.
sql/sql_acl.cc:
No thd==0 in tables_ok().
sql/sql_parse.cc:
Binlogging of CALL (and not of the substatements of the SP).
If SP returns error, we don't binlog it (see comment); we push warning in this case.
Binlogging of ALTER|DROP PROCEDURE|FUNCTION with safety messages.
2005-05-05 14:20:53 +02:00
select * from t2;
a
23
drop function fn1;
create function fn1()
returns int
2005-11-10 17:50:51 +01:00
no sql
Approximative fixes for BUG#2610,2611,9100 i.e. WL#2146 binlogging/replication of routines (stored procs and functions).
Approximative, because it's using our binlogging way (what we call "query"-level) and this is not as good as record-level binlog (5.1) would be. It imposes several
limitations to routines, and has caveats (which I'll document, and for which the server will try to issue errors but that is not always possible).
Reason I don't propagate caller info to the binlog as planned is that on master and slave
users may be different; even with that some caveats would remain.
mysql-test/mysql-test-run.sh:
In the testsuite we know what we do, we are not creating nasty routines, and breaking binlog is ok except in rpl_sp.
mysql-test/r/blackhole.result:
Updating results now that 4.1 has been merged
mysql-test/valgrind.supp:
Some suppressions for Valgrind (useful on my machine Suse 9.1);
this is just adding to the already existing suppressions of pthread and dl.
sql/item_func.cc:
Don't binlog the substatements when executing a function. If the function
is declared to modify data and does not complete, warning "broken binlog".
Note that SELECT myfunc() will not be binlogged even if myfunc() updates data (will be documented);
but INSERT INTO t VALUES(myfunc()) will be binlogged (what decides is if the caller
gets binlogged; the function changes nothing to binlogging).
sql/log_event.cc:
Just making functions which can be re-used when we binlog more strings
in status_vars in Query_log_event (e.g. one day "user", "host").
sql/log_event.h:
comment
sql/mysql_priv.h:
--log-bin-trust-routine-creators
sql/mysqld.cc:
--log-bin-trust-routine-creators
sql/set_var.cc:
--log-bin-trust-routine-creators
sql/share/errmsg.txt:
error messages to warn about problems with routines and binlog
sql/slave.cc:
If in a routine, replication table inclusion/exclusion rules always answer "replicate!" (see comment in code).
sql/sp.cc:
If binlog is on: errors if one wants to create a non-deterministic update routine
(repeatability problem - note that the test is not perfect for functions) or does not have SUPER (because routines can easily
be made to destroy slave's data with just CREATE ROUTINE and EXECUTE priv on master).
--log-bin-trust-routine-creators removes these errors.
Binlogging of CREATE PROCEDURE|FUNCTION.
sql/sql_acl.cc:
No thd==0 in tables_ok().
sql/sql_parse.cc:
Binlogging of CALL (and not of the substatements of the SP).
If SP returns error, we don't binlog it (see comment); we push warning in this case.
Binlogging of ALTER|DROP PROCEDURE|FUNCTION with safety messages.
2005-05-05 14:20:53 +02:00
begin
return unix_timestamp();
end|
2005-11-10 17:50:51 +01:00
alter function fn1 contains sql;
ERROR HY000: This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA in its declaration and binary logging is enabled (you *might* want to use the less safe log_bin_trust_function_creators variable)
Approximative fixes for BUG#2610,2611,9100 i.e. WL#2146 binlogging/replication of routines (stored procs and functions).
Approximative, because it's using our binlogging way (what we call "query"-level) and this is not as good as record-level binlog (5.1) would be. It imposes several
limitations to routines, and has caveats (which I'll document, and for which the server will try to issue errors but that is not always possible).
Reason I don't propagate caller info to the binlog as planned is that on master and slave
users may be different; even with that some caveats would remain.
mysql-test/mysql-test-run.sh:
In the testsuite we know what we do, we are not creating nasty routines, and breaking binlog is ok except in rpl_sp.
mysql-test/r/blackhole.result:
Updating results now that 4.1 has been merged
mysql-test/valgrind.supp:
Some suppressions for Valgrind (useful on my machine Suse 9.1);
this is just adding to the already existing suppressions of pthread and dl.
sql/item_func.cc:
Don't binlog the substatements when executing a function. If the function
is declared to modify data and does not complete, warning "broken binlog".
Note that SELECT myfunc() will not be binlogged even if myfunc() updates data (will be documented);
but INSERT INTO t VALUES(myfunc()) will be binlogged (what decides is if the caller
gets binlogged; the function changes nothing to binlogging).
sql/log_event.cc:
Just making functions which can be re-used when we binlog more strings
in status_vars in Query_log_event (e.g. one day "user", "host").
sql/log_event.h:
comment
sql/mysql_priv.h:
--log-bin-trust-routine-creators
sql/mysqld.cc:
--log-bin-trust-routine-creators
sql/set_var.cc:
--log-bin-trust-routine-creators
sql/share/errmsg.txt:
error messages to warn about problems with routines and binlog
sql/slave.cc:
If in a routine, replication table inclusion/exclusion rules always answer "replicate!" (see comment in code).
sql/sp.cc:
If binlog is on: errors if one wants to create a non-deterministic update routine
(repeatability problem - note that the test is not perfect for functions) or does not have SUPER (because routines can easily
be made to destroy slave's data with just CREATE ROUTINE and EXECUTE priv on master).
--log-bin-trust-routine-creators removes these errors.
Binlogging of CREATE PROCEDURE|FUNCTION.
sql/sql_acl.cc:
No thd==0 in tables_ok().
sql/sql_parse.cc:
Binlogging of CALL (and not of the substatements of the SP).
If SP returns error, we don't binlog it (see comment); we push warning in this case.
Binlogging of ALTER|DROP PROCEDURE|FUNCTION with safety messages.
2005-05-05 14:20:53 +02:00
delete from t1;
set timestamp=1000000000;
insert into t1 values(fn1());
2005-11-10 17:50:51 +01:00
create function fn2()
returns int
no sql
begin
return unix_timestamp();
end|
ERROR HY000: You do not have the SUPER privilege and binary logging is enabled (you *might* want to use the less safe log_bin_trust_function_creators variable)
set global log_bin_trust_routine_creators=1;
Warnings:
Warning 1287 'log_bin_trust_routine_creators' is deprecated; use 'log_bin_trust_function_creators' instead
set global log_bin_trust_function_creators=0;
set global log_bin_trust_function_creators=1;
set global log_bin_trust_function_creators=1;
create function fn2()
returns int
no sql
begin
return unix_timestamp();
end|
create function fn3()
returns int
not deterministic
reads sql data
begin
return 0;
end|
select fn3();
fn3()
0
Approximative fixes for BUG#2610,2611,9100 i.e. WL#2146 binlogging/replication of routines (stored procs and functions).
Approximative, because it's using our binlogging way (what we call "query"-level) and this is not as good as record-level binlog (5.1) would be. It imposes several
limitations to routines, and has caveats (which I'll document, and for which the server will try to issue errors but that is not always possible).
Reason I don't propagate caller info to the binlog as planned is that on master and slave
users may be different; even with that some caveats would remain.
mysql-test/mysql-test-run.sh:
In the testsuite we know what we do, we are not creating nasty routines, and breaking binlog is ok except in rpl_sp.
mysql-test/r/blackhole.result:
Updating results now that 4.1 has been merged
mysql-test/valgrind.supp:
Some suppressions for Valgrind (useful on my machine Suse 9.1);
this is just adding to the already existing suppressions of pthread and dl.
sql/item_func.cc:
Don't binlog the substatements when executing a function. If the function
is declared to modify data and does not complete, warning "broken binlog".
Note that SELECT myfunc() will not be binlogged even if myfunc() updates data (will be documented);
but INSERT INTO t VALUES(myfunc()) will be binlogged (what decides is if the caller
gets binlogged; the function changes nothing to binlogging).
sql/log_event.cc:
Just making functions which can be re-used when we binlog more strings
in status_vars in Query_log_event (e.g. one day "user", "host").
sql/log_event.h:
comment
sql/mysql_priv.h:
--log-bin-trust-routine-creators
sql/mysqld.cc:
--log-bin-trust-routine-creators
sql/set_var.cc:
--log-bin-trust-routine-creators
sql/share/errmsg.txt:
error messages to warn about problems with routines and binlog
sql/slave.cc:
If in a routine, replication table inclusion/exclusion rules always answer "replicate!" (see comment in code).
sql/sp.cc:
If binlog is on: errors if one wants to create a non-deterministic update routine
(repeatability problem - note that the test is not perfect for functions) or does not have SUPER (because routines can easily
be made to destroy slave's data with just CREATE ROUTINE and EXECUTE priv on master).
--log-bin-trust-routine-creators removes these errors.
Binlogging of CREATE PROCEDURE|FUNCTION.
sql/sql_acl.cc:
No thd==0 in tables_ok().
sql/sql_parse.cc:
Binlogging of CALL (and not of the substatements of the SP).
If SP returns error, we don't binlog it (see comment); we push warning in this case.
Binlogging of ALTER|DROP PROCEDURE|FUNCTION with safety messages.
2005-05-05 14:20:53 +02:00
select * from mysql.proc where db='mysqltest1';
db name type specific_name language sql_data_access is_deterministic security_type param_list returns body definer created modified sql_mode comment
2005-11-10 17:50:51 +01:00
mysqltest1 fn1 FUNCTION fn1 SQL NO_SQL NO DEFINER int(11) begin
return unix_timestamp();
end root@localhost # #
mysqltest1 fn2 FUNCTION fn2 SQL NO_SQL NO DEFINER int(11) begin
Approximative fixes for BUG#2610,2611,9100 i.e. WL#2146 binlogging/replication of routines (stored procs and functions).
Approximative, because it's using our binlogging way (what we call "query"-level) and this is not as good as record-level binlog (5.1) would be. It imposes several
limitations to routines, and has caveats (which I'll document, and for which the server will try to issue errors but that is not always possible).
Reason I don't propagate caller info to the binlog as planned is that on master and slave
users may be different; even with that some caveats would remain.
mysql-test/mysql-test-run.sh:
In the testsuite we know what we do, we are not creating nasty routines, and breaking binlog is ok except in rpl_sp.
mysql-test/r/blackhole.result:
Updating results now that 4.1 has been merged
mysql-test/valgrind.supp:
Some suppressions for Valgrind (useful on my machine Suse 9.1);
this is just adding to the already existing suppressions of pthread and dl.
sql/item_func.cc:
Don't binlog the substatements when executing a function. If the function
is declared to modify data and does not complete, warning "broken binlog".
Note that SELECT myfunc() will not be binlogged even if myfunc() updates data (will be documented);
but INSERT INTO t VALUES(myfunc()) will be binlogged (what decides is if the caller
gets binlogged; the function changes nothing to binlogging).
sql/log_event.cc:
Just making functions which can be re-used when we binlog more strings
in status_vars in Query_log_event (e.g. one day "user", "host").
sql/log_event.h:
comment
sql/mysql_priv.h:
--log-bin-trust-routine-creators
sql/mysqld.cc:
--log-bin-trust-routine-creators
sql/set_var.cc:
--log-bin-trust-routine-creators
sql/share/errmsg.txt:
error messages to warn about problems with routines and binlog
sql/slave.cc:
If in a routine, replication table inclusion/exclusion rules always answer "replicate!" (see comment in code).
sql/sp.cc:
If binlog is on: errors if one wants to create a non-deterministic update routine
(repeatability problem - note that the test is not perfect for functions) or does not have SUPER (because routines can easily
be made to destroy slave's data with just CREATE ROUTINE and EXECUTE priv on master).
--log-bin-trust-routine-creators removes these errors.
Binlogging of CREATE PROCEDURE|FUNCTION.
sql/sql_acl.cc:
No thd==0 in tables_ok().
sql/sql_parse.cc:
Binlogging of CALL (and not of the substatements of the SP).
If SP returns error, we don't binlog it (see comment); we push warning in this case.
Binlogging of ALTER|DROP PROCEDURE|FUNCTION with safety messages.
2005-05-05 14:20:53 +02:00
return unix_timestamp();
2005-11-10 17:50:51 +01:00
end zedjzlcsjhd@localhost # #
mysqltest1 fn3 FUNCTION fn3 SQL READS_SQL_DATA NO DEFINER int(11) begin
return 0;
Approximative fixes for BUG#2610,2611,9100 i.e. WL#2146 binlogging/replication of routines (stored procs and functions).
Approximative, because it's using our binlogging way (what we call "query"-level) and this is not as good as record-level binlog (5.1) would be. It imposes several
limitations to routines, and has caveats (which I'll document, and for which the server will try to issue errors but that is not always possible).
Reason I don't propagate caller info to the binlog as planned is that on master and slave
users may be different; even with that some caveats would remain.
mysql-test/mysql-test-run.sh:
In the testsuite we know what we do, we are not creating nasty routines, and breaking binlog is ok except in rpl_sp.
mysql-test/r/blackhole.result:
Updating results now that 4.1 has been merged
mysql-test/valgrind.supp:
Some suppressions for Valgrind (useful on my machine Suse 9.1);
this is just adding to the already existing suppressions of pthread and dl.
sql/item_func.cc:
Don't binlog the substatements when executing a function. If the function
is declared to modify data and does not complete, warning "broken binlog".
Note that SELECT myfunc() will not be binlogged even if myfunc() updates data (will be documented);
but INSERT INTO t VALUES(myfunc()) will be binlogged (what decides is if the caller
gets binlogged; the function changes nothing to binlogging).
sql/log_event.cc:
Just making functions which can be re-used when we binlog more strings
in status_vars in Query_log_event (e.g. one day "user", "host").
sql/log_event.h:
comment
sql/mysql_priv.h:
--log-bin-trust-routine-creators
sql/mysqld.cc:
--log-bin-trust-routine-creators
sql/set_var.cc:
--log-bin-trust-routine-creators
sql/share/errmsg.txt:
error messages to warn about problems with routines and binlog
sql/slave.cc:
If in a routine, replication table inclusion/exclusion rules always answer "replicate!" (see comment in code).
sql/sp.cc:
If binlog is on: errors if one wants to create a non-deterministic update routine
(repeatability problem - note that the test is not perfect for functions) or does not have SUPER (because routines can easily
be made to destroy slave's data with just CREATE ROUTINE and EXECUTE priv on master).
--log-bin-trust-routine-creators removes these errors.
Binlogging of CREATE PROCEDURE|FUNCTION.
sql/sql_acl.cc:
No thd==0 in tables_ok().
sql/sql_parse.cc:
Binlogging of CALL (and not of the substatements of the SP).
If SP returns error, we don't binlog it (see comment); we push warning in this case.
Binlogging of ALTER|DROP PROCEDURE|FUNCTION with safety messages.
2005-05-05 14:20:53 +02:00
end root@localhost # #
select * from t1;
a
1000000000
use mysqltest1;
select * from t1;
a
1000000000
select * from mysql.proc where db='mysqltest1';
db name type specific_name language sql_data_access is_deterministic security_type param_list returns body definer created modified sql_mode comment
2005-11-10 17:50:51 +01:00
mysqltest1 fn1 FUNCTION fn1 SQL NO_SQL NO DEFINER int(11) begin
return unix_timestamp();
2006-03-02 13:18:49 +01:00
end root@localhost # #
2005-11-10 17:50:51 +01:00
mysqltest1 fn2 FUNCTION fn2 SQL NO_SQL NO DEFINER int(11) begin
Approximative fixes for BUG#2610,2611,9100 i.e. WL#2146 binlogging/replication of routines (stored procs and functions).
Approximative, because it's using our binlogging way (what we call "query"-level) and this is not as good as record-level binlog (5.1) would be. It imposes several
limitations to routines, and has caveats (which I'll document, and for which the server will try to issue errors but that is not always possible).
Reason I don't propagate caller info to the binlog as planned is that on master and slave
users may be different; even with that some caveats would remain.
mysql-test/mysql-test-run.sh:
In the testsuite we know what we do, we are not creating nasty routines, and breaking binlog is ok except in rpl_sp.
mysql-test/r/blackhole.result:
Updating results now that 4.1 has been merged
mysql-test/valgrind.supp:
Some suppressions for Valgrind (useful on my machine Suse 9.1);
this is just adding to the already existing suppressions of pthread and dl.
sql/item_func.cc:
Don't binlog the substatements when executing a function. If the function
is declared to modify data and does not complete, warning "broken binlog".
Note that SELECT myfunc() will not be binlogged even if myfunc() updates data (will be documented);
but INSERT INTO t VALUES(myfunc()) will be binlogged (what decides is if the caller
gets binlogged; the function changes nothing to binlogging).
sql/log_event.cc:
Just making functions which can be re-used when we binlog more strings
in status_vars in Query_log_event (e.g. one day "user", "host").
sql/log_event.h:
comment
sql/mysql_priv.h:
--log-bin-trust-routine-creators
sql/mysqld.cc:
--log-bin-trust-routine-creators
sql/set_var.cc:
--log-bin-trust-routine-creators
sql/share/errmsg.txt:
error messages to warn about problems with routines and binlog
sql/slave.cc:
If in a routine, replication table inclusion/exclusion rules always answer "replicate!" (see comment in code).
sql/sp.cc:
If binlog is on: errors if one wants to create a non-deterministic update routine
(repeatability problem - note that the test is not perfect for functions) or does not have SUPER (because routines can easily
be made to destroy slave's data with just CREATE ROUTINE and EXECUTE priv on master).
--log-bin-trust-routine-creators removes these errors.
Binlogging of CREATE PROCEDURE|FUNCTION.
sql/sql_acl.cc:
No thd==0 in tables_ok().
sql/sql_parse.cc:
Binlogging of CALL (and not of the substatements of the SP).
If SP returns error, we don't binlog it (see comment); we push warning in this case.
Binlogging of ALTER|DROP PROCEDURE|FUNCTION with safety messages.
2005-05-05 14:20:53 +02:00
return unix_timestamp();
2006-03-02 13:18:49 +01:00
end zedjzlcsjhd@localhost # #
2005-11-10 17:50:51 +01:00
mysqltest1 fn3 FUNCTION fn3 SQL READS_SQL_DATA NO DEFINER int(11) begin
return 0;
2006-03-02 13:18:49 +01:00
end root@localhost # #
2005-11-10 17:50:51 +01:00
delete from t2;
alter table t2 add unique (a);
drop function fn1;
Fix for BUG#14769 "Function fails to replicate if fails half-way (slave stops)":
if the function, invoked in a non-binlogged caller (e.g. SELECT, DO), failed half-way on the master,
slave would stop and complain that error code between him and master mismatch.
To solve this, when a stored function is invoked in a non-binlogged caller (e.g. SELECT, DO), we binlog the function
call as SELECT instead of as DO (see revision comment of sp_head.cc for more).
And: minor wording change in the help text.
This cset will cause conflicts in 5.1, I'll merge.
mysql-test/r/rpl_sp.result:
result update
mysql-test/t/rpl_sp-slave.opt:
bug just fixed so option not needed
mysql-test/t/rpl_sp.test:
test for more half-failed functions with DO and SELECT, to test the bug of this changeset.
cleanup at the end.
sql/mysqld.cc:
function -> stored function (change suggested by Paul)
sql/sp_head.cc:
When a function updates data and is called from a non-binlogged statement (SELECT, DO), we binlog it
as SELECT myfunc(), and not DO myfunc() like before.
2006-02-18 17:26:30 +01:00
create function fn1(x int)
2005-11-10 17:50:51 +01:00
returns int
begin
Fix for BUG#14769 "Function fails to replicate if fails half-way (slave stops)":
if the function, invoked in a non-binlogged caller (e.g. SELECT, DO), failed half-way on the master,
slave would stop and complain that error code between him and master mismatch.
To solve this, when a stored function is invoked in a non-binlogged caller (e.g. SELECT, DO), we binlog the function
call as SELECT instead of as DO (see revision comment of sp_head.cc for more).
And: minor wording change in the help text.
This cset will cause conflicts in 5.1, I'll merge.
mysql-test/r/rpl_sp.result:
result update
mysql-test/t/rpl_sp-slave.opt:
bug just fixed so option not needed
mysql-test/t/rpl_sp.test:
test for more half-failed functions with DO and SELECT, to test the bug of this changeset.
cleanup at the end.
sql/mysqld.cc:
function -> stored function (change suggested by Paul)
sql/sp_head.cc:
When a function updates data and is called from a non-binlogged statement (SELECT, DO), we binlog it
as SELECT myfunc(), and not DO myfunc() like before.
2006-02-18 17:26:30 +01:00
insert into t2 values(x),(x);
2005-11-10 17:50:51 +01:00
return 10;
end|
Fix for BUG#14769 "Function fails to replicate if fails half-way (slave stops)":
if the function, invoked in a non-binlogged caller (e.g. SELECT, DO), failed half-way on the master,
slave would stop and complain that error code between him and master mismatch.
To solve this, when a stored function is invoked in a non-binlogged caller (e.g. SELECT, DO), we binlog the function
call as SELECT instead of as DO (see revision comment of sp_head.cc for more).
And: minor wording change in the help text.
This cset will cause conflicts in 5.1, I'll merge.
mysql-test/r/rpl_sp.result:
result update
mysql-test/t/rpl_sp-slave.opt:
bug just fixed so option not needed
mysql-test/t/rpl_sp.test:
test for more half-failed functions with DO and SELECT, to test the bug of this changeset.
cleanup at the end.
sql/mysqld.cc:
function -> stored function (change suggested by Paul)
sql/sp_head.cc:
When a function updates data and is called from a non-binlogged statement (SELECT, DO), we binlog it
as SELECT myfunc(), and not DO myfunc() like before.
2006-02-18 17:26:30 +01:00
do fn1(100);
Warnings:
Error 1062 Duplicate entry '100' for key 1
select fn1(20);
2005-11-10 17:50:51 +01:00
ERROR 23000: Duplicate entry '20' for key 1
select * from t2;
a
20
Fix for BUG#14769 "Function fails to replicate if fails half-way (slave stops)":
if the function, invoked in a non-binlogged caller (e.g. SELECT, DO), failed half-way on the master,
slave would stop and complain that error code between him and master mismatch.
To solve this, when a stored function is invoked in a non-binlogged caller (e.g. SELECT, DO), we binlog the function
call as SELECT instead of as DO (see revision comment of sp_head.cc for more).
And: minor wording change in the help text.
This cset will cause conflicts in 5.1, I'll merge.
mysql-test/r/rpl_sp.result:
result update
mysql-test/t/rpl_sp-slave.opt:
bug just fixed so option not needed
mysql-test/t/rpl_sp.test:
test for more half-failed functions with DO and SELECT, to test the bug of this changeset.
cleanup at the end.
sql/mysqld.cc:
function -> stored function (change suggested by Paul)
sql/sp_head.cc:
When a function updates data and is called from a non-binlogged statement (SELECT, DO), we binlog it
as SELECT myfunc(), and not DO myfunc() like before.
2006-02-18 17:26:30 +01:00
100
2005-11-10 17:50:51 +01:00
select * from t2;
a
20
Fix for BUG#14769 "Function fails to replicate if fails half-way (slave stops)":
if the function, invoked in a non-binlogged caller (e.g. SELECT, DO), failed half-way on the master,
slave would stop and complain that error code between him and master mismatch.
To solve this, when a stored function is invoked in a non-binlogged caller (e.g. SELECT, DO), we binlog the function
call as SELECT instead of as DO (see revision comment of sp_head.cc for more).
And: minor wording change in the help text.
This cset will cause conflicts in 5.1, I'll merge.
mysql-test/r/rpl_sp.result:
result update
mysql-test/t/rpl_sp-slave.opt:
bug just fixed so option not needed
mysql-test/t/rpl_sp.test:
test for more half-failed functions with DO and SELECT, to test the bug of this changeset.
cleanup at the end.
sql/mysqld.cc:
function -> stored function (change suggested by Paul)
sql/sp_head.cc:
When a function updates data and is called from a non-binlogged statement (SELECT, DO), we binlog it
as SELECT myfunc(), and not DO myfunc() like before.
2006-02-18 17:26:30 +01:00
100
2005-05-06 18:52:19 +02:00
create trigger trg before insert on t1 for each row set new.a= 10;
ERROR 42000: Access denied; you need the SUPER privilege for this operation
delete from t1;
create trigger trg before insert on t1 for each row set new.a= 10;
insert into t1 values (1);
select * from t1;
a
10
select * from t1;
a
10
delete from t1;
2005-07-19 18:06:49 +02:00
drop trigger trg;
2005-05-06 18:52:19 +02:00
insert into t1 values (1);
select * from t1;
a
1
2005-11-10 17:50:51 +01:00
show binlog events in 'master-bin.000001' from 98;
2005-05-06 18:52:19 +02:00
Log_name Pos Event_type Server_id End_log_pos Info
2005-11-11 01:28:35 +01:00
master-bin.000001 # Query 1 # drop database if exists mysqltest1
master-bin.000001 # Query 1 # create database mysqltest1
master-bin.000001 # Query 1 # use `mysqltest1`; create table t1 (a varchar(100))
2006-03-02 13:18:49 +01:00
master-bin.000001 # Query 1 # use `mysqltest1`; CREATE DEFINER=`root`@`localhost` procedure foo()
2005-11-11 01:28:35 +01:00
begin
declare b int;
set b = 8;
insert into t1 values (b);
insert into t1 values (unix_timestamp());
end
master-bin.000001 # Query 1 # use `mysqltest1`; insert into t1 values ( NAME_CONST('b',8))
master-bin.000001 # Query 1 # use `mysqltest1`; insert into t1 values (unix_timestamp())
master-bin.000001 # Query 1 # use `mysqltest1`; delete from t1
2006-03-02 13:18:49 +01:00
master-bin.000001 # Query 1 # use `mysqltest1`; CREATE DEFINER=`root`@`localhost` procedure foo2()
2005-11-11 01:28:35 +01:00
select * from mysqltest1.t1
master-bin.000001 # Query 1 # use `mysqltest1`; alter procedure foo2 contains sql
master-bin.000001 # Query 1 # use `mysqltest1`; drop table t1
master-bin.000001 # Query 1 # use `mysqltest1`; create table t1 (a int)
master-bin.000001 # Query 1 # use `mysqltest1`; create table t2 like t1
2006-03-02 13:18:49 +01:00
master-bin.000001 # Query 1 # use `mysqltest1`; CREATE DEFINER=`root`@`localhost` procedure foo3()
2005-11-11 01:28:35 +01:00
deterministic
insert into t1 values (15)
master-bin.000001 # Query 1 # use `mysqltest1`; grant CREATE ROUTINE, EXECUTE on mysqltest1.* to "zedjzlcsjhd"@127.0.0.1
master-bin.000001 # Query 1 # use `mysqltest1`; grant SELECT on mysqltest1.t1 to "zedjzlcsjhd"@127.0.0.1
master-bin.000001 # Query 1 # use `mysqltest1`; grant SELECT, INSERT on mysqltest1.t2 to "zedjzlcsjhd"@127.0.0.1
2006-03-02 13:18:49 +01:00
master-bin.000001 # Query 1 # use `mysqltest1`; CREATE DEFINER=`zedjzlcsjhd`@`127.0.0.1` procedure foo4()
2005-11-11 01:28:35 +01:00
deterministic
begin
insert into t2 values(3);
insert into t1 values (5);
end
master-bin.000001 # Query 1 # use `mysqltest1`; insert into t2 values(3)
master-bin.000001 # Query 1 # use `mysqltest1`; insert into t1 values (15)
master-bin.000001 # Query 1 # use `mysqltest1`; insert into t2 values(3)
master-bin.000001 # Query 1 # use `mysqltest1`; alter procedure foo4 sql security invoker
master-bin.000001 # Query 1 # use `mysqltest1`; insert into t2 values(3)
master-bin.000001 # Query 1 # use `mysqltest1`; insert into t1 values (5)
master-bin.000001 # Query 1 # use `mysqltest1`; delete from t2
master-bin.000001 # Query 1 # use `mysqltest1`; alter table t2 add unique (a)
master-bin.000001 # Query 1 # use `mysqltest1`; drop procedure foo4
2006-03-02 13:18:49 +01:00
master-bin.000001 # Query 1 # use `mysqltest1`; CREATE DEFINER=`root`@`localhost` procedure foo4()
2005-11-11 01:28:35 +01:00
deterministic
begin
insert into t2 values(20),(20);
end
master-bin.000001 # Query 1 # use `mysqltest1`; insert into t2 values(20),(20)
master-bin.000001 # Query 1 # use `mysqltest1`; drop procedure foo4
master-bin.000001 # Query 1 # use `mysqltest1`; drop procedure foo
master-bin.000001 # Query 1 # use `mysqltest1`; drop procedure foo2
master-bin.000001 # Query 1 # use `mysqltest1`; drop procedure foo3
2006-03-02 13:18:49 +01:00
master-bin.000001 # Query 1 # use `mysqltest1`; CREATE DEFINER=`root`@`localhost` function fn1(x int)
2005-11-11 01:28:35 +01:00
returns int
deterministic
begin
insert into t1 values (x);
return x+2;
end
master-bin.000001 # Query 1 # use `mysqltest1`; delete t1,t2 from t1,t2
Fix for BUG#14769 "Function fails to replicate if fails half-way (slave stops)":
if the function, invoked in a non-binlogged caller (e.g. SELECT, DO), failed half-way on the master,
slave would stop and complain that error code between him and master mismatch.
To solve this, when a stored function is invoked in a non-binlogged caller (e.g. SELECT, DO), we binlog the function
call as SELECT instead of as DO (see revision comment of sp_head.cc for more).
And: minor wording change in the help text.
This cset will cause conflicts in 5.1, I'll merge.
mysql-test/r/rpl_sp.result:
result update
mysql-test/t/rpl_sp-slave.opt:
bug just fixed so option not needed
mysql-test/t/rpl_sp.test:
test for more half-failed functions with DO and SELECT, to test the bug of this changeset.
cleanup at the end.
sql/mysqld.cc:
function -> stored function (change suggested by Paul)
sql/sp_head.cc:
When a function updates data and is called from a non-binlogged statement (SELECT, DO), we binlog it
as SELECT myfunc(), and not DO myfunc() like before.
2006-02-18 17:26:30 +01:00
master-bin.000001 # Query 1 # use `mysqltest1`; SELECT `fn1`(20)
2005-11-11 01:28:35 +01:00
master-bin.000001 # Query 1 # use `mysqltest1`; insert into t2 values(fn1(21))
master-bin.000001 # Query 1 # use `mysqltest1`; drop function fn1
2006-03-02 13:18:49 +01:00
master-bin.000001 # Query 1 # use `mysqltest1`; CREATE DEFINER=`root`@`localhost` function fn1()
2005-11-11 01:28:35 +01:00
returns int
no sql
begin
return unix_timestamp();
end
master-bin.000001 # Query 1 # use `mysqltest1`; delete from t1
master-bin.000001 # Query 1 # use `mysqltest1`; insert into t1 values(fn1())
2006-03-02 13:18:49 +01:00
master-bin.000001 # Query 1 # use `mysqltest1`; CREATE DEFINER=`zedjzlcsjhd`@`127.0.0.1` function fn2()
2005-11-11 01:28:35 +01:00
returns int
no sql
begin
return unix_timestamp();
end
2006-03-02 13:18:49 +01:00
master-bin.000001 # Query 1 # use `mysqltest1`; CREATE DEFINER=`root`@`localhost` function fn3()
2005-11-11 01:28:35 +01:00
returns int
not deterministic
reads sql data
begin
return 0;
end
master-bin.000001 # Query 1 # use `mysqltest1`; delete from t2
master-bin.000001 # Query 1 # use `mysqltest1`; alter table t2 add unique (a)
master-bin.000001 # Query 1 # use `mysqltest1`; drop function fn1
2006-03-02 13:18:49 +01:00
master-bin.000001 # Query 1 # use `mysqltest1`; CREATE DEFINER=`root`@`localhost` function fn1(x int)
2005-11-11 01:28:35 +01:00
returns int
begin
Fix for BUG#14769 "Function fails to replicate if fails half-way (slave stops)":
if the function, invoked in a non-binlogged caller (e.g. SELECT, DO), failed half-way on the master,
slave would stop and complain that error code between him and master mismatch.
To solve this, when a stored function is invoked in a non-binlogged caller (e.g. SELECT, DO), we binlog the function
call as SELECT instead of as DO (see revision comment of sp_head.cc for more).
And: minor wording change in the help text.
This cset will cause conflicts in 5.1, I'll merge.
mysql-test/r/rpl_sp.result:
result update
mysql-test/t/rpl_sp-slave.opt:
bug just fixed so option not needed
mysql-test/t/rpl_sp.test:
test for more half-failed functions with DO and SELECT, to test the bug of this changeset.
cleanup at the end.
sql/mysqld.cc:
function -> stored function (change suggested by Paul)
sql/sp_head.cc:
When a function updates data and is called from a non-binlogged statement (SELECT, DO), we binlog it
as SELECT myfunc(), and not DO myfunc() like before.
2006-02-18 17:26:30 +01:00
insert into t2 values(x),(x);
2005-11-11 01:28:35 +01:00
return 10;
end
Fix for BUG#14769 "Function fails to replicate if fails half-way (slave stops)":
if the function, invoked in a non-binlogged caller (e.g. SELECT, DO), failed half-way on the master,
slave would stop and complain that error code between him and master mismatch.
To solve this, when a stored function is invoked in a non-binlogged caller (e.g. SELECT, DO), we binlog the function
call as SELECT instead of as DO (see revision comment of sp_head.cc for more).
And: minor wording change in the help text.
This cset will cause conflicts in 5.1, I'll merge.
mysql-test/r/rpl_sp.result:
result update
mysql-test/t/rpl_sp-slave.opt:
bug just fixed so option not needed
mysql-test/t/rpl_sp.test:
test for more half-failed functions with DO and SELECT, to test the bug of this changeset.
cleanup at the end.
sql/mysqld.cc:
function -> stored function (change suggested by Paul)
sql/sp_head.cc:
When a function updates data and is called from a non-binlogged statement (SELECT, DO), we binlog it
as SELECT myfunc(), and not DO myfunc() like before.
2006-02-18 17:26:30 +01:00
master-bin.000001 # Query 1 # use `mysqltest1`; SELECT `fn1`(100)
master-bin.000001 # Query 1 # use `mysqltest1`; SELECT `fn1`(20)
2005-11-11 01:28:35 +01:00
master-bin.000001 # Query 1 # use `mysqltest1`; delete from t1
master-bin.000001 # Query 1 # use `mysqltest1`; CREATE DEFINER=`root`@`localhost` trigger trg before insert on t1 for each row set new.a= 10
master-bin.000001 # Query 1 # use `mysqltest1`; insert into t1 values (1)
master-bin.000001 # Query 1 # use `mysqltest1`; delete from t1
master-bin.000001 # Query 1 # use `mysqltest1`; drop trigger trg
master-bin.000001 # Query 1 # use `mysqltest1`; insert into t1 values (1)
2005-05-06 18:52:19 +02:00
select * from t1;
a
1
2005-10-12 21:42:51 +02:00
create procedure foo()
not deterministic
reads sql data
select * from t1;
call foo();
a
1
drop procedure foo;
Approximative fixes for BUG#2610,2611,9100 i.e. WL#2146 binlogging/replication of routines (stored procs and functions).
Approximative, because it's using our binlogging way (what we call "query"-level) and this is not as good as record-level binlog (5.1) would be. It imposes several
limitations to routines, and has caveats (which I'll document, and for which the server will try to issue errors but that is not always possible).
Reason I don't propagate caller info to the binlog as planned is that on master and slave
users may be different; even with that some caveats would remain.
mysql-test/mysql-test-run.sh:
In the testsuite we know what we do, we are not creating nasty routines, and breaking binlog is ok except in rpl_sp.
mysql-test/r/blackhole.result:
Updating results now that 4.1 has been merged
mysql-test/valgrind.supp:
Some suppressions for Valgrind (useful on my machine Suse 9.1);
this is just adding to the already existing suppressions of pthread and dl.
sql/item_func.cc:
Don't binlog the substatements when executing a function. If the function
is declared to modify data and does not complete, warning "broken binlog".
Note that SELECT myfunc() will not be binlogged even if myfunc() updates data (will be documented);
but INSERT INTO t VALUES(myfunc()) will be binlogged (what decides is if the caller
gets binlogged; the function changes nothing to binlogging).
sql/log_event.cc:
Just making functions which can be re-used when we binlog more strings
in status_vars in Query_log_event (e.g. one day "user", "host").
sql/log_event.h:
comment
sql/mysql_priv.h:
--log-bin-trust-routine-creators
sql/mysqld.cc:
--log-bin-trust-routine-creators
sql/set_var.cc:
--log-bin-trust-routine-creators
sql/share/errmsg.txt:
error messages to warn about problems with routines and binlog
sql/slave.cc:
If in a routine, replication table inclusion/exclusion rules always answer "replicate!" (see comment in code).
sql/sp.cc:
If binlog is on: errors if one wants to create a non-deterministic update routine
(repeatability problem - note that the test is not perfect for functions) or does not have SUPER (because routines can easily
be made to destroy slave's data with just CREATE ROUTINE and EXECUTE priv on master).
--log-bin-trust-routine-creators removes these errors.
Binlogging of CREATE PROCEDURE|FUNCTION.
sql/sql_acl.cc:
No thd==0 in tables_ok().
sql/sql_parse.cc:
Binlogging of CALL (and not of the substatements of the SP).
If SP returns error, we don't binlog it (see comment); we push warning in this case.
Binlogging of ALTER|DROP PROCEDURE|FUNCTION with safety messages.
2005-05-05 14:20:53 +02:00
drop function fn1;
drop database mysqltest1;
drop user "zedjzlcsjhd"@127.0.0.1;
2005-11-17 01:15:10 +01:00
use test;
use test;
drop function if exists f1;
create function f1() returns int reads sql data
begin
declare var integer;
declare c cursor for select a from v1;
open c;
fetch c into var;
close c;
return var;
end|
create view v1 as select 1 as a;
create table t1 (a int);
insert into t1 (a) values (f1());
select * from t1;
a
1
drop view v1;
drop function f1;
select * from t1;
a
1
2006-01-20 15:21:39 +01:00
DROP PROCEDURE IF EXISTS p1;
DROP TABLE IF EXISTS t1;
CREATE TABLE t1(col VARCHAR(10));
CREATE PROCEDURE p1(arg VARCHAR(10))
INSERT INTO t1 VALUES(arg);
CALL p1('test');
SELECT * FROM t1;
col
test
SELECT * FROM t1;
col
test
DROP PROCEDURE p1;
2006-07-28 00:49:18 +02:00
---> Test for BUG#20438
---> Preparing environment...
---> connection: master
DROP PROCEDURE IF EXISTS p1;
DROP FUNCTION IF EXISTS f1;
---> Synchronizing slave with master...
---> connection: master
---> Creating procedure...
/*!50003 CREATE PROCEDURE p1() SET @a = 1 */;
/*!50003 CREATE FUNCTION f1() RETURNS INT RETURN 0 */;
---> Checking on master...
SHOW CREATE PROCEDURE p1;
Procedure sql_mode Create Procedure
p1 CREATE DEFINER=`root`@`localhost` PROCEDURE `p1`()
SET @a = 1
SHOW CREATE FUNCTION f1;
Function sql_mode Create Function
f1 CREATE DEFINER=`root`@`localhost` FUNCTION `f1`() RETURNS int(11)
RETURN 0
---> Synchronizing slave with master...
---> connection: master
---> Checking on slave...
SHOW CREATE PROCEDURE p1;
Procedure sql_mode Create Procedure
p1 CREATE DEFINER=`root`@`localhost` PROCEDURE `p1`()
SET @a = 1
SHOW CREATE FUNCTION f1;
Function sql_mode Create Function
f1 CREATE DEFINER=`root`@`localhost` FUNCTION `f1`() RETURNS int(11)
RETURN 0
---> connection: master
---> Cleaning up...
DROP PROCEDURE p1;
DROP FUNCTION f1;
2005-11-17 01:15:10 +01:00
drop table t1;