2007-11-23 12:51:14 +01:00
|
|
|
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
|
2007-09-06 12:06:22 -06:00
|
|
|
--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
|
2007-09-06 12:06:22 -06:00
|
|
|
--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;
|
2008-04-05 21:33:42 +04:00
|
|
|
--sync_slave_with_master
|