mariadb/mysql-test/t/insert_notembedded.test

191 lines
6.4 KiB
Text
Raw Normal View History

several fixes to make tests pass in embedded-server mode libmysqld/lib_sql.cc: check for bootstrap added mysql-test/include/federated.inc: disabled in embedded mysql-test/mysql-test-run.pl: we disable ssh in embedded server mysql-test/r/bdb.result: part moved to bdb_notembedded as it uses binlog mysql-test/r/flush_block_commit.result: part moved to flush_block_commit_notembedded mysql-test/r/insert.result: part moved to insert_notembedded as delayed works differently in embedded server mysql-test/r/insert_select.result: part moved to insert_notembedded as GRANTS usually disabled in embedded server mysql-test/r/join.result: access rights hidden in result mysql-test/t/backup.test: now available in embedded server mysql-test/t/bdb.test: part moved to bdb_notembedded as it uses binlog mysql-test/t/delayed.test: code trimmed mysql-test/t/execution_constants.test: skipped in embedded-server mode mysql-test/t/flush_block_commit.test: moved to flush_block_commit_notembedded mysql-test/t/information_schema_db.test: skipped in embedded-server mysql-test/t/innodb.test: directories replaced to be embedded-server compliant mysql-test/t/insert.test: part moved to insert_notembedded mysql-test/t/insert_select.test: part moved to insert_notembedded mysql-test/t/join.test: access rights hidden mysql-test/t/status.test: skipped in embedded server mysql-test/t/trigger.test: directories replaced to be embedded-server compliant sql/item_strfunc.cc: extra contexts not needed whan access checks disabled sql/share/errmsg.txt: bigger paths reserved to prevent test's fails mysql-test/r/bdb_notembedded.result: ***MISSING WEAVE*** mysql-test/r/flush_block_commit_notembedded.result: added mysql-test/r/insert_notembedded.result: added mysql-test/t/bdb_notembedded.test: ***MISSING WEAVE*** mysql-test/t/flush_block_commit_notembedded.test: added mysql-test/t/insert_notembedded.test: added
2006-11-13 20:06:45 +04:00
-- source include/not_embedded.inc
--disable_warnings
drop table if exists t1;
--enable_warnings
# Test for INSERT DELAYED INTO a <view>
# BUG#13683: INSERT DELAYED into a view creates an infinite loop
#
create table t1 (n int);
create view v1 as select * from t1;
--error 1347
insert delayed into v1 values (1);
drop table t1;
drop view v1;
#
# Bug #20989: View '(null).(null)' references invalid table(s)... on
# SQL SECURITY INVOKER
#
# this is really the fact that REPLACE ... SELECT required additional
# INSERT privs (on tables that are part of a view) over the related
# REPLACE, SELECT
#
CREATE DATABASE meow;
connect (root,localhost,root,,meow);
connection root;
CREATE TABLE table_target ( mexs_id CHAR(8), messzeit TIMESTAMP, PRIMARY KEY (mexs_id));
CREATE TABLE table_target2 ( mexs_id CHAR(8), messzeit TIMESTAMP, PRIMARY KEY (mexs_id));
CREATE TABLE table_target3 ( mexs_id CHAR(8), messzeit TIMESTAMP, PRIMARY KEY (mexs_id));
CREATE VIEW view_target2 AS SELECT mexs_id,messzeit FROM table_target2;
CREATE SQL SECURITY INVOKER VIEW view_target3 AS SELECT mexs_id,messzeit FROM table_target3;
CREATE TABLE table_stations ( mexs_id VARCHAR(8), icao VARCHAR(4), country CHAR(2), PRIMARY KEY (mexs_id), UNIQUE KEY icao (icao), KEY country (country), CONSTRAINT stations_ibfk_8 FOREIGN KEY (country) REFERENCES countries (country) ON UPDATE CASCADE);
INSERT INTO table_stations VALUES ('87654321','XXXX','YY');
CREATE TABLE table_countries ( country CHAR(2), iso_short_en VARCHAR(64), PRIMARY KEY (country));
INSERT INTO table_countries VALUES ('YY','Entenhausen');
CREATE ALGORITHM=MERGE SQL SECURITY INVOKER VIEW view_stations AS select table_stations.mexs_id AS mexs_id, table_stations.icao AS icao, table_stations.country AS landescode from (table_stations join table_countries on((table_stations.country = table_countries.country)));
CREATE TABLE table_source ( id varchar(4), datetime TIMESTAMP, PRIMARY KEY (id));
INSERT INTO table_source VALUES ('XXXX','2006-07-12 07:50:00');
GRANT SELECT ON table_source TO user20989@localhost;
GRANT SELECT ON table_countries TO user20989@localhost;
GRANT SELECT ON table_stations TO user20989@localhost;
GRANT SELECT ON view_stations TO user20989@localhost;
GRANT SELECT ON table_target TO user20989@localhost;
GRANT SELECT ON table_target2 TO user20989@localhost;
GRANT INSERT,DELETE,SELECT ON view_target3 TO user20989@localhost;
connect (user20989,localhost,user20989,,meow);
connection user20989;
--error 1142
REPLACE INTO table_target
SELECT stations.mexs_id AS mexs_id, datetime AS messzeit
FROM table_source
INNER JOIN view_stations AS stations
ON table_source.id = stations.icao
LEFT JOIN table_target AS old
USING (mexs_id);
--error 1142
REPLACE INTO view_target2
SELECT stations.mexs_id AS mexs_id, datetime AS messzeit
FROM table_source
INNER JOIN view_stations AS stations
ON table_source.id = stations.icao
LEFT JOIN view_target2 AS old
USING (mexs_id);
--error 1356
REPLACE INTO view_target3
SELECT stations.mexs_id AS mexs_id, datetime AS messzeit
FROM table_source
INNER JOIN view_stations AS stations
ON table_source.id = stations.icao
LEFT JOIN view_target3 AS old
USING (mexs_id);
connection root;
disconnect user20989;
GRANT INSERT,DELETE ON table_target TO user20989@localhost;
GRANT INSERT,DELETE,SELECT ON view_target2 TO user20989@localhost;
GRANT INSERT,DELETE,SELECT ON table_target3 TO user20989@localhost;
connect (user20989,localhost,user20989,,meow);
connection user20989;
REPLACE INTO table_target
SELECT stations.mexs_id AS mexs_id, datetime AS messzeit
FROM table_source
INNER JOIN view_stations AS stations
ON table_source.id = stations.icao
LEFT JOIN table_target AS old
USING (mexs_id);
--error 1142
REPLACE INTO table_target2 VALUES ('00X45Y78','2006-07-12 07:50:00');
REPLACE INTO view_target2 VALUES ('12X45Y78','2006-07-12 07:50:00');
SELECT stations.mexs_id AS mexs_id, datetime AS messzeit
FROM table_source
INNER JOIN view_stations AS stations
ON table_source.id = stations.icao
LEFT JOIN view_target2 AS old
USING (mexs_id);
REPLACE INTO view_target2
SELECT stations.mexs_id AS mexs_id, datetime AS messzeit
FROM table_source
INNER JOIN view_stations AS stations
ON table_source.id = stations.icao
LEFT JOIN view_target2 AS old
USING (mexs_id);
REPLACE INTO view_target3
SELECT stations.mexs_id AS mexs_id, datetime AS messzeit
FROM table_source
INNER JOIN view_stations AS stations
ON table_source.id = stations.icao
LEFT JOIN view_target3 AS old
USING (mexs_id);
connection root;
disconnect user20989;
SELECT * FROM table_target;
SELECT * FROM view_target2;
SELECT * FROM view_target3;
DROP VIEW view_stations;
DROP TABLE table_source;
DROP TABLE table_countries;
DROP TABLE table_stations;
DROP TABLE table_target;
DROP TABLE table_target2;
DROP TABLE table_target3;
DROP VIEW view_target2;
DROP VIEW view_target3;
DROP USER user20989@localhost;
disconnect root;
connection default;
DROP DATABASE meow;
#
# Bug#28587 SELECT is blocked by INSERT waiting on read lock, even with low_priority_updates
#
--echo connection: default
set low_priority_updates=1;
--disable_warnings
drop table if exists t1;
--enable_warnings
create table t1 (a int, b int, unique key t1$a (a));
lock table t1 read;
connect (update,localhost,root,,);
connection update;
--echo connection: update
set low_priority_updates=1;
show variables like 'low_priority_updates';
let $ID= `select connection_id()`;
--send insert into t1 values (1, 2) ON DUPLICATE KEY UPDATE b = 2;
connection default;
# we must wait till the insert opens and locks the table
let $wait_condition=
select count(*) = 1 from information_schema.processlist
Backport of: ------------------------------------------------------------ revno: 3035.4.1 committer: Davi Arnaut <Davi.Arnaut@Sun.COM> branch nick: 39897-6.0 timestamp: Thu 2009-01-15 12:17:57 -0200 message: Bug#39897: lock_multi fails in pushbuild: timeout waiting for processlist The problem is that relying on the "Table lock" thread state in its current position to detect that a thread is waiting on a lock is race prone. The "Table lock" state change happens before the thread actually tries to grab a lock on a table. The solution is to move the "Table lock" state so that its set only when a thread is actually going to wait for a lock. The state change happens after the thread fails to grab the lock (because it is owned by other thread) and proceeds to wait on a condition. This is considered part of work related to WL#4284 "Transactional DDL locking" Warning: this patch contains an incompatible change. When waiting on a lock in thr_lock.c, the server used to display "Locked" processlist state. After this patch, the state is "Table lock". The new state was actually intended to be display since year 2002, when Monty added it. But up until removal of thd->locked boolean member, this state was ignored by SHOW PROCESSLIST code. mysql-test/r/lock_multi.result: A style fix. mysql-test/r/sp-threads.result: Changed output of SHOW PROCESSLIST (new wait state). mysql-test/t/lock_multi.test: Use a more accurate state description when waiting inside thr_lock.c. mysql-test/t/lock_sync.test: Use a more accurate state description when waiting inside thr_lock.c. mysql-test/t/multi_update.test: Use a more accurate state description when waiting inside thr_lock.c. mysql-test/t/query_cache_28249.test: Use a more accurate state description when waiting inside thr_lock.c. mysql-test/t/sp_notembedded.test: Use a more accurate state description when waiting inside thr_lock.c. mysql-test/t/status.test: Use a more accurate state description when waiting inside thr_lock.c. mysys/thr_lock.c: Update thread state while waiting for a table lock. sql/lock.cc: State change was moved inside thr_lock.c.
2009-12-03 23:08:27 +03:00
where state = "Table lock" and id = $ID;
--source include/wait_condition.inc
connect (select,localhost,root,,);
--echo connection: select
select * from t1;
connection default;
--echo connection: default
select * from t1;
connection default;
disconnect update;
disconnect select;
Backport of: ------------------------------------------------------------ revno: 2476.784.3 committer: davi@moksha.local timestamp: Tue 2007-10-02 21:27:31 -0300 message: Bug#25858 Some DROP TABLE under LOCK TABLES can cause deadlocks When a client (connection) holds a lock on a table and attempts to drop (obtain a exclusive lock) on a second table that is already held by a second client and the second client then attempts to drop the table that is held by the first client, leads to a circular wait deadlock. This scenario is very similar to trying to drop (or rename) a table while holding read locks and are correctly forbidden. The solution is to allow a drop table operation to continue only if the table being dropped is write (exclusively) locked, or if the table is temporary, or if the client is not holding any locks. Using this scheme prevents the creation of a circular chain in which each client is waiting for one table that the next client in the chain is holding. This is incompatible change, as can be seen by number of tests cases that needed to be fixed, but is consistent with respect to behavior of the different scenarios in which the circular wait might happen. mysql-test/r/drop.result: Test case result for Bug#25858 mysql-test/r/group_by.result: Fix test case result wrt drop table under lock tables -- unlock tables before dropping table. mysql-test/r/insert_notembedded.result: Fix test case result wrt drop table under lock tables -- unlock tables before dropping table mysql-test/r/lock.result: Fix test case result wrt drop table under lock tables -- unlock tables before dropping table. mysql-test/r/lock_multi.result: Fix test case result wrt drop table under lock tables -- unlock tables before dropping table. mysql-test/r/myisam.result: Fix test case result wrt drop table under lock tables -- unlock tables before dropping table. mysql-test/r/view.result: Fix test case result wrt drop table under lock tables -- unlock tables before dropping table. mysql-test/t/drop.test: Add test case for Bug#25858 mysql-test/t/group_by.test: Fix test case: unlock tables in preparation for a drop table. In some circumstances, dropping tables while holding locks leads to a deadlock. mysql-test/t/insert_notembedded.test: Fix test case: unlock tables in preparation for a drop table. In some circumstances, dropping tables while holding locks leads to a deadlock. mysql-test/t/lock.test: Fix test case: unlock tables in preparation for a drop table. In some circumstances, dropping tables while holding locks leads to a deadlock. mysql-test/t/lock_multi.test: Fix test case: unlock tables in preparation for a drop table. In some circumstances, dropping tables while holding locks leads to a deadlock. mysql-test/t/myisam.test: Fix test case: unlock tables in preparation for a drop table. In some circumstances, dropping tables while holding locks leads to a deadlock. mysql-test/t/query_cache_notembedded.test: Fix test case: unlock tables in preparation for a drop table. In some circumstances, dropping tables while holding locks leads to a deadlock. mysql-test/t/view.test: Fix test case: unlock tables in preparation for a drop table. In some circumstances, dropping tables while holding locks leads to a deadlock. sql/lock.cc: When trying to obtain a name lock under lock tables, ensure that the table is properly exclusively locked and fail otherwise.
2009-11-20 22:51:12 +03:00
unlock tables;
drop table t1;
set low_priority_updates=default;