mirror/mariadb
1
0
Fork 0
mirror of https://github.com/MariaDB/server.git synced 2025-01-16 03:52:35 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
mariadb/mysql-test/suite/federated/federated_innodb.test

40 lines
1.1 KiB
Text
Raw Normal View History

Bug#40645 Test main.federated_innodb does not always clean up after itself Reordered include files so that no mess will be left if this test is run without InnoDB Previously, this test would leave a database named 'federated' in such a case and would cause tests that examined existing databases to fail.
2008-11-13 22:01:01 +01:00
# NOTE: Keep any include/ files that will kill / skip a test BEFORE any others
# having federated.inc before have_innodb.inc allows for an orphaned database
# that can cause other tests to fail.
# See Bug #40645 Test main.federated_innodb does not always clean up after itself
Bug#25513 "Federared Transactions Failure" Bug occurs when the user performs an operation which inserts more than one row into the federated table and the federated table references a remote table stored within a transactional storage engine. When the insert operation for any one row in the statement fails due to constraint violation, the federated engine is unable to perform statement rollback and so the remote table contains a partial commit. The user would expect a statement to perform the same so a statement rollback is expected. This bug was fixed by implementing bulk-insert handling into the federated storage engine. This will relieve the bug for most common situations by enabling the generation of a multi-row insert into the remote table and thus permitting the remote table to perform statement rollback when neccessary. The multi-row insert is limited to the maximum packet size between servers and should the size overflow, more than one insert statement will be sent and this bug will reappear. Multi-row insert is disabled when an "INSERT...ON DUPLICATE KEY UPDATE" is being performed. The bulk-insert handling will offer a significant performance boost when inserting a large number of small rows. This patch builds on Bug29019 and Bug25511 sql/ha_federated.cc: bug25513 new member methods: start_bulk_insert() - initializes memory for bulk insert end_bulk_insert() - sends any remaining bulk insert and frees memory append_stmt_insert() - create the INSERT statement sql/ha_federated.h: bug25513 new member value: bulk_insert new member methods: start_bulk_insert(), end_bulk_insert(), append_stmt_insert() make member methods private: read_next(), index_read_idx_with_result_set() mysql-test/r/federated_innodb.result: New BitKeeper file ``mysql-test/r/federated_innodb.result'' mysql-test/t/federated_innodb-slave.opt: New BitKeeper file ``mysql-test/t/federated_innodb-slave.opt'' mysql-test/t/federated_innodb.test: New BitKeeper file ``mysql-test/t/federated_innodb.test''
2007-06-29 01:03:01 +02:00
source include/have_innodb.inc;
Bug #12876932 - INCORRECT SELECT RESULT ON FEDERATED TABLE Problem description: Table 't' created with two colums having compound index on both the columns under innodb/myisam engine at remote machine. In the local machine same table is created undet the federated engine. A select having where clause with along 'AND' operation gives wrong results on local machine. Analysis: The given query at federated engine is wrongly transformed by federated::create_where_from_key() function and the same was sent to the remote machine. Hence the local machine is showing wrong results. Given query "select c1 from t where c1 <= 2 and c2 = 1;" Query transformed, after ha_federated::create_where_from_key() function is: SELECT `c1`, `c2` FROM `t` WHERE (`c1` IS NOT NULL ) AND ( (`c1` >= 2) AND (`c2` <= 1) ) and the same sent to real_query(). In the above the '<=' and '=' conditions were transformed to '>=' and '<=' respectively. ha_federated::create_where_from_key() function behaving as below: The key_range is having both the start_key and end_key. The start_key is used to get "(`c1` IS NOT NULL )" part of the where clause, this transformation is correct. The end_key is used to get "( (`c1` >= 2) AND (`c2` <= 1) )", which is wrong, here the given conditions('<=' and '=') are changed as wrong conditions('>=' and '<='). The end_key is having {key = 0x39fa6d0 "", length = 10, keypart_map = 3, flag = HA_READ_AFTER_KEY} The store_length is having value '5'. Based on store_length and length values the condition values is applied in HA_READ_AFTER_KEY switch case. The switch case 'HA_READ_AFTER_KEY' is applicable to only the last part of the end_key and for previous parts it is going to 'HA_READ_KEY_OR_NEXT' case, here the '>=' is getting added as a condition instead of '<='. Fix: Updated the 'if' condition in 'HA_READ_AFTER_KEY' case to affect for all parts of the end_key. i.e 'i > 0' will used for end_key, Hence added it in the if condition. mysql-test/suite/federated/federated.test: modified the federated.inc file location mysql-test/suite/federated/federated_archive.test: modified the federated.inc file location mysql-test/suite/federated/federated_bug_13118.test: modified the federated.inc file location mysql-test/suite/federated/federated_bug_25714.test: modified the federated.inc file location mysql-test/suite/federated/federated_bug_35333.test: modified the federated.inc file location mysql-test/suite/federated/federated_debug.test: modified the federated.inc file location mysql-test/suite/federated/federated_innodb.test: modified the federated.inc file location mysql-test/suite/federated/federated_server.test: modified the federated.inc file location mysql-test/suite/federated/federated_transactions.test: modified the federated.inc file location mysql-test/suite/federated/include/federated.inc: moved the file from federated suite to federated/include folder mysql-test/suite/federated/include/federated_cleanup.inc: moved the file from federated suite to federated/include folder mysql-test/suite/federated/include/have_federated_db.inc: moved the file from federated suite to federated/include folder storage/federated/ha_federated.cc: updated the 'if condition' in ha_federated::create_where_from_key() function.
2012-07-26 11:39:22 +02:00
source suite/federated/include/federated.inc;
Bug#25513 "Federared Transactions Failure" Bug occurs when the user performs an operation which inserts more than one row into the federated table and the federated table references a remote table stored within a transactional storage engine. When the insert operation for any one row in the statement fails due to constraint violation, the federated engine is unable to perform statement rollback and so the remote table contains a partial commit. The user would expect a statement to perform the same so a statement rollback is expected. This bug was fixed by implementing bulk-insert handling into the federated storage engine. This will relieve the bug for most common situations by enabling the generation of a multi-row insert into the remote table and thus permitting the remote table to perform statement rollback when neccessary. The multi-row insert is limited to the maximum packet size between servers and should the size overflow, more than one insert statement will be sent and this bug will reappear. Multi-row insert is disabled when an "INSERT...ON DUPLICATE KEY UPDATE" is being performed. The bulk-insert handling will offer a significant performance boost when inserting a large number of small rows. This patch builds on Bug29019 and Bug25511 sql/ha_federated.cc: bug25513 new member methods: start_bulk_insert() - initializes memory for bulk insert end_bulk_insert() - sends any remaining bulk insert and frees memory append_stmt_insert() - create the INSERT statement sql/ha_federated.h: bug25513 new member value: bulk_insert new member methods: start_bulk_insert(), end_bulk_insert(), append_stmt_insert() make member methods private: read_next(), index_read_idx_with_result_set() mysql-test/r/federated_innodb.result: New BitKeeper file ``mysql-test/r/federated_innodb.result'' mysql-test/t/federated_innodb-slave.opt: New BitKeeper file ``mysql-test/t/federated_innodb-slave.opt'' mysql-test/t/federated_innodb.test: New BitKeeper file ``mysql-test/t/federated_innodb.test''
2007-06-29 01:03:01 +02:00
#
# Bug#25513 Federated transaction failures
#
connection slave;
create table federated.t1 (a int primary key, b varchar(64))
engine=myisam;
connection master;
--replace_result $SLAVE_MYPORT SLAVE_PORT
eval create table federated.t1 (a int primary key, b varchar(64))
engine=federated
connection='mysql://root@127.0.0.1:$SLAVE_MYPORT/federated/t1';
--error ER_DUP_KEY
insert into federated.t1 values (1,"Larry"), (2,"Curly"), (1,"Moe");
select * from federated.t1;
connection slave;
truncate federated.t1;
alter table federated.t1 engine=innodb;
connection master;
--error ER_DUP_KEY
insert into federated.t1 values (1,"Larry"), (2,"Curly"), (1,"Moe");
select * from federated.t1;
drop table federated.t1;
connection slave;
drop table federated.t1;
Bug #12876932 - INCORRECT SELECT RESULT ON FEDERATED TABLE Problem description: Table 't' created with two colums having compound index on both the columns under innodb/myisam engine at remote machine. In the local machine same table is created undet the federated engine. A select having where clause with along 'AND' operation gives wrong results on local machine. Analysis: The given query at federated engine is wrongly transformed by federated::create_where_from_key() function and the same was sent to the remote machine. Hence the local machine is showing wrong results. Given query "select c1 from t where c1 <= 2 and c2 = 1;" Query transformed, after ha_federated::create_where_from_key() function is: SELECT `c1`, `c2` FROM `t` WHERE (`c1` IS NOT NULL ) AND ( (`c1` >= 2) AND (`c2` <= 1) ) and the same sent to real_query(). In the above the '<=' and '=' conditions were transformed to '>=' and '<=' respectively. ha_federated::create_where_from_key() function behaving as below: The key_range is having both the start_key and end_key. The start_key is used to get "(`c1` IS NOT NULL )" part of the where clause, this transformation is correct. The end_key is used to get "( (`c1` >= 2) AND (`c2` <= 1) )", which is wrong, here the given conditions('<=' and '=') are changed as wrong conditions('>=' and '<='). The end_key is having {key = 0x39fa6d0 "", length = 10, keypart_map = 3, flag = HA_READ_AFTER_KEY} The store_length is having value '5'. Based on store_length and length values the condition values is applied in HA_READ_AFTER_KEY switch case. The switch case 'HA_READ_AFTER_KEY' is applicable to only the last part of the end_key and for previous parts it is going to 'HA_READ_KEY_OR_NEXT' case, here the '>=' is getting added as a condition instead of '<='. Fix: Updated the 'if' condition in 'HA_READ_AFTER_KEY' case to affect for all parts of the end_key. i.e 'i > 0' will used for end_key, Hence added it in the if condition. mysql-test/suite/federated/federated.test: modified the federated.inc file location mysql-test/suite/federated/federated_archive.test: modified the federated.inc file location mysql-test/suite/federated/federated_bug_13118.test: modified the federated.inc file location mysql-test/suite/federated/federated_bug_25714.test: modified the federated.inc file location mysql-test/suite/federated/federated_bug_35333.test: modified the federated.inc file location mysql-test/suite/federated/federated_debug.test: modified the federated.inc file location mysql-test/suite/federated/federated_innodb.test: modified the federated.inc file location mysql-test/suite/federated/federated_server.test: modified the federated.inc file location mysql-test/suite/federated/federated_transactions.test: modified the federated.inc file location mysql-test/suite/federated/include/federated.inc: moved the file from federated suite to federated/include folder mysql-test/suite/federated/include/federated_cleanup.inc: moved the file from federated suite to federated/include folder mysql-test/suite/federated/include/have_federated_db.inc: moved the file from federated suite to federated/include folder storage/federated/ha_federated.cc: updated the 'if condition' in ha_federated::create_where_from_key() function.
2012-07-26 11:39:22 +02:00
source suite/federated/include/federated_cleanup.inc;
Reference in a new issue Copy permalink