mariadb/mysql-test/t/rpl_get_lock.test
unknown 5a5fc3433c Last part of fix for BUG#7998 "Replication should be more clever about when to replicate RELEASE_LOCK()" + fixes after merge
mysql-test/r/drop_temp_table.result:
  result update
mysql-test/r/mix_innodb_myisam_binlog.result:
  result update
mysql-test/r/rpl000001.result:
  result update
mysql-test/r/rpl_change_master.result:
  result update
mysql-test/r/rpl_deadlock.result:
  result update (merge)
mysql-test/t/rpl000001.test:
  can't rely on GET_LOCK() to do slave synchro (use table lock instead)
mysql-test/t/rpl_change_master.test:
  changing the test as we can't use GET_LOCK() for slave synchro
mysql-test/t/rpl_deadlock.test:
  update (merge) binlog positions
mysql-test/t/rpl_get_lock.test:
  comment
2005-03-02 17:52:38 +01:00

41 lines
1.2 KiB
Text

source include/master-slave.inc;
create table t1(n int);
insert into t1 values(get_lock("lock",2));
dirty_close master;
connection master1;
select get_lock("lock",2);
select release_lock("lock");
#ignore
disable_query_log;
let $1=2000;
while ($1)
{
do get_lock("lock",2);
do release_lock("lock");
dec $1;
}
enable_query_log;
save_master_pos;
connection slave;
sync_with_master;
select get_lock("lock",3);
select * from t1;
# There is no point in testing REPLICATIION of the IS_*_LOCK
# functions; slave does not run with the same concurrency context as
# master (generally in slave we can't know that on master this lock
# was already held by another connection and so that the the
# get_lock() we're replicating timed out on master hence returned 0,
# or that the is_free_lock() we're playing returned 0 etc.
# But here all we do is test these functions outside of replication.
select is_free_lock("lock"), is_used_lock("lock") = connection_id();
explain extended select is_free_lock("lock"), is_used_lock("lock");
# Check lock functions
select is_free_lock("lock2");
select is_free_lock(NULL);
connection master1;
drop table t1;
save_master_pos;
connection slave;
sync_with_master;