mariadb/mysql-test/suite/rpl/t/rpl_binlog_grant.test

46 lines
1 KiB
Text
Raw Normal View History

source include/master-slave.inc;
Bug#21975 Grant and revoke statements are non-transactional Bug#21422 GRANT/REVOKE possible inside stored function, probably in a trigger Bug#17244 GRANT gives strange error message when used in a stored function GRANT/REVOKE statements are non-transactional (no explicit transaction boundaries) in nature and hence are forbidden inside stored functions and triggers, but they weren't being effectively forbidden. Furthermore, the absence of implict commits makes changes made by GRANT/REVOKE statements to not be rolled back. The implemented fix is to issue a implicit commit with every GRANT/REVOKE statement, effectively prohibiting these statements in stored functions and triggers. The implicit commit also fixes the replication bug, and looks like being in concert with the behavior of DDL and administrative statements. Since this is a incompatible change, the following sentence should be added to the Manual in the very end of the 3rd paragraph, subclause 13.4.3 "Statements That Cause an Implicit Commit": "Beginning with MySQL 5.0.??, the GRANT and REVOKE statements cause an implicit commit." Patch contributed by Vladimir Shebordaev mysql-test/r/sp-error.result: Test case result for Bug#17244 mysql-test/t/sp-error.test: Test case for Bug#17244 sql/sp_head.cc: Set that a procedure with GRANT/REVOKE command has a (implicit or explicit) commit. sql/sql_parse.cc: End active transaction in SQLCOM_GRANT and SQLCOM_REVOKE, and thus effectively prohibit these statements in stored functions and triggers. An implicit commit also fixes a bug in replication, when GRANT or REVOKE would disappear from the binary log in case of a subsequent ROLLBACK, since they were considered transactional statements. mysql-test/suite/rpl/r/rpl_binlog_grant.result: Add test case result for Bug#21975 mysql-test/suite/rpl/t/rpl_binlog_grant.test: Add test case for Bug#21975
2007-08-29 16:59:38 -03:00
-- source include/have_innodb.inc
-- source include/not_embedded.inc
-- source include/have_binlog_format_mixed_or_statement.inc
let $VERSION=`select version()`;
# Bug #21975: grant/revoke statements in transaction
# used to disappear from binlog upon rallback.
# Now GRANT/REVOKE do implicitly commit
# transaction
--disable_warnings
drop database if exists d1;
--enable_warnings
create database d1;
use d1;
create table t (s1 int) engine=innodb;
set @@autocommit=0;
start transaction;
insert into t values (1);
grant select on t to x@y;
#
# There is no active transaction here
#
rollback;
show grants for x@y;
--replace_result $VERSION VERSION
--replace_regex /\/\* xid=.* \*\//\/* XID *\//
Bug#21975 Grant and revoke statements are non-transactional Bug#21422 GRANT/REVOKE possible inside stored function, probably in a trigger Bug#17244 GRANT gives strange error message when used in a stored function GRANT/REVOKE statements are non-transactional (no explicit transaction boundaries) in nature and hence are forbidden inside stored functions and triggers, but they weren't being effectively forbidden. Furthermore, the absence of implict commits makes changes made by GRANT/REVOKE statements to not be rolled back. The implemented fix is to issue a implicit commit with every GRANT/REVOKE statement, effectively prohibiting these statements in stored functions and triggers. The implicit commit also fixes the replication bug, and looks like being in concert with the behavior of DDL and administrative statements. Since this is a incompatible change, the following sentence should be added to the Manual in the very end of the 3rd paragraph, subclause 13.4.3 "Statements That Cause an Implicit Commit": "Beginning with MySQL 5.0.??, the GRANT and REVOKE statements cause an implicit commit." Patch contributed by Vladimir Shebordaev mysql-test/r/sp-error.result: Test case result for Bug#17244 mysql-test/t/sp-error.test: Test case for Bug#17244 sql/sp_head.cc: Set that a procedure with GRANT/REVOKE command has a (implicit or explicit) commit. sql/sql_parse.cc: End active transaction in SQLCOM_GRANT and SQLCOM_REVOKE, and thus effectively prohibit these statements in stored functions and triggers. An implicit commit also fixes a bug in replication, when GRANT or REVOKE would disappear from the binary log in case of a subsequent ROLLBACK, since they were considered transactional statements. mysql-test/suite/rpl/r/rpl_binlog_grant.result: Add test case result for Bug#21975 mysql-test/suite/rpl/t/rpl_binlog_grant.test: Add test case for Bug#21975
2007-08-29 16:59:38 -03:00
show binlog events;
start transaction;
insert into t values (2);
revoke select on t from x@y;
#
# There is no active transaction here
#
commit;
select * from t;
show grants for x@y;
--replace_result $VERSION VERSION
--replace_regex /\/\* xid=.* \*\//\/* XID *\//
Bug#21975 Grant and revoke statements are non-transactional Bug#21422 GRANT/REVOKE possible inside stored function, probably in a trigger Bug#17244 GRANT gives strange error message when used in a stored function GRANT/REVOKE statements are non-transactional (no explicit transaction boundaries) in nature and hence are forbidden inside stored functions and triggers, but they weren't being effectively forbidden. Furthermore, the absence of implict commits makes changes made by GRANT/REVOKE statements to not be rolled back. The implemented fix is to issue a implicit commit with every GRANT/REVOKE statement, effectively prohibiting these statements in stored functions and triggers. The implicit commit also fixes the replication bug, and looks like being in concert with the behavior of DDL and administrative statements. Since this is a incompatible change, the following sentence should be added to the Manual in the very end of the 3rd paragraph, subclause 13.4.3 "Statements That Cause an Implicit Commit": "Beginning with MySQL 5.0.??, the GRANT and REVOKE statements cause an implicit commit." Patch contributed by Vladimir Shebordaev mysql-test/r/sp-error.result: Test case result for Bug#17244 mysql-test/t/sp-error.test: Test case for Bug#17244 sql/sp_head.cc: Set that a procedure with GRANT/REVOKE command has a (implicit or explicit) commit. sql/sql_parse.cc: End active transaction in SQLCOM_GRANT and SQLCOM_REVOKE, and thus effectively prohibit these statements in stored functions and triggers. An implicit commit also fixes a bug in replication, when GRANT or REVOKE would disappear from the binary log in case of a subsequent ROLLBACK, since they were considered transactional statements. mysql-test/suite/rpl/r/rpl_binlog_grant.result: Add test case result for Bug#21975 mysql-test/suite/rpl/t/rpl_binlog_grant.test: Add test case for Bug#21975
2007-08-29 16:59:38 -03:00
show binlog events;
drop user x@y;
drop database d1;
--sync_slave_with_master