mariadb/mysql-test/suite/rpl/r/rpl_binlog_grant.result

55 lines
1.8 KiB
Text
Raw Normal View History

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;
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
drop database if exists d1;
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;
rollback;
show grants for x@y;
Grants for x@y
GRANT USAGE ON *.* TO 'x'@'y'
GRANT SELECT ON `d1`.`t` TO 'x'@'y'
show binlog events from <binlog_start>;
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
Log_name Pos Event_type Server_id End_log_pos Info
master-bin.000001 # Query # # drop database if exists d1
master-bin.000001 # Query # # create database d1
master-bin.000001 # Query # # use `d1`; create table t (s1 int) engine=innodb
master-bin.000001 # Query # # BEGIN
master-bin.000001 # Query # # use `d1`; insert into t values (1)
master-bin.000001 # Xid # # COMMIT /* XID */
master-bin.000001 # Query # # use `d1`; grant select on t to x@y
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
start transaction;
insert into t values (2);
revoke select on t from x@y;
commit;
select * from t;
s1
1
2
show grants for x@y;
Grants for x@y
GRANT USAGE ON *.* TO 'x'@'y'
show binlog events from <binlog_start>;
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
Log_name Pos Event_type Server_id End_log_pos Info
master-bin.000001 # Query # # drop database if exists d1
master-bin.000001 # Query # # create database d1
master-bin.000001 # Query # # use `d1`; create table t (s1 int) engine=innodb
master-bin.000001 # Query # # BEGIN
master-bin.000001 # Query # # use `d1`; insert into t values (1)
master-bin.000001 # Xid # # COMMIT /* XID */
master-bin.000001 # Query # # use `d1`; grant select on t to x@y
master-bin.000001 # Query # # BEGIN
master-bin.000001 # Query # # use `d1`; insert into t values (2)
master-bin.000001 # Xid # # COMMIT /* XID */
master-bin.000001 # Query # # use `d1`; revoke select on t from x@y
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
drop user x@y;
drop database d1;