2010-11-30 18:20:56 +01:00
|
|
|
--echo #
|
|
|
|
--echo # Bug 35333 "If a Federated table can't connect to the remote hose, can't retrieve metadata"
|
|
|
|
--echo #
|
|
|
|
--echo # Queries such as SHOW TABLE STATUS and SELECT * FROM INFORMATION_SCHEMA.TABLES fail
|
|
|
|
--echo # when encountering a federated table that cannot connect to its remote table.
|
|
|
|
--echo #
|
|
|
|
--echo # The fix is to store the error text in the TABLE COMMENTS column of I_S.TABLES, clear
|
|
|
|
--echo # the remote connection error and push a warning instead. This allows the SELECT operation
|
|
|
|
--echo # to complete while still indicating a problem. This fix applies to any non-fatal system
|
|
|
|
--echo # error that occurs during a query against I_S.TABLES.de
|
|
|
|
|
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
|
2010-11-30 18:20:56 +01:00
|
|
|
|
|
|
|
--disable_warnings
|
|
|
|
# Federated database exists
|
|
|
|
DROP TABLE IF EXISTS federated.t0;
|
|
|
|
--enable_warnings
|
|
|
|
|
2011-07-02 22:12:12 +02:00
|
|
|
--disable_parsing
|
|
|
|
# This test doesn't work with federatedx, as it doesn't allow wrong connections
|
|
|
|
|
2010-11-30 18:20:56 +01:00
|
|
|
--echo #
|
|
|
|
--echo # Create the base table to be referenced
|
|
|
|
--echo #
|
|
|
|
CREATE TABLE realdb.t0 (a text, b text) ENGINE=MYISAM;
|
|
|
|
|
|
|
|
--echo #
|
|
|
|
--echo # Create a federated table with a bogus port number
|
|
|
|
--echo #
|
|
|
|
CREATE TABLE federated.t0 (a text, b text) ENGINE=FEDERATED
|
|
|
|
CONNECTION='mysql://root@127.0.0.1:63333/realdb/t0';
|
|
|
|
|
|
|
|
#--warning ER_CONNECT_TO_FOREIGN_DATA_SOURCE
|
|
|
|
|
|
|
|
--echo #
|
|
|
|
--echo # Trigger a federated system error during a INFORMATION_SCHEMA.TABLES query
|
|
|
|
--echo #
|
|
|
|
# Remove O/S-specific socket error
|
|
|
|
--replace_regex /\(.*\)/(socket errno)/
|
|
|
|
SELECT TABLE_SCHEMA, TABLE_NAME, TABLE_TYPE, ENGINE, ROW_FORMAT, TABLE_ROWS, DATA_LENGTH, TABLE_COMMENT
|
|
|
|
FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA = 'realdb' or TABLE_SCHEMA = 'federated';
|
|
|
|
|
|
|
|
# Remove O/S-specific socket error
|
|
|
|
--replace_regex /\(.*\)/(socket errno)/
|
|
|
|
SHOW WARNINGS;
|
2011-07-02 22:12:12 +02:00
|
|
|
DROP TABLE federated.t0;
|
|
|
|
|
|
|
|
--enable_parsing
|
2010-11-30 18:20:56 +01:00
|
|
|
|
|
|
|
--echo #
|
|
|
|
--echo # Create a MyISAM table then corrupt the file
|
|
|
|
--echo #
|
|
|
|
CREATE TABLE t1 (c1 int) ENGINE=MYISAM;
|
|
|
|
--echo #
|
|
|
|
--echo # Corrupt the MyISAM table by deleting the base file
|
|
|
|
--echo #
|
|
|
|
let $MYSQLD_DATADIR= `SELECT @@datadir`;
|
2011-07-02 22:12:12 +02:00
|
|
|
--remove_file $MYSQLD_DATADIR/test/t1.MYD
|
|
|
|
--remove_file $MYSQLD_DATADIR/test/t1.MYI
|
2010-11-30 18:20:56 +01:00
|
|
|
|
|
|
|
--echo #
|
|
|
|
--echo # Trigger a MyISAM system error during an INFORMATION_SCHEMA.TABLES query
|
|
|
|
--echo #
|
|
|
|
SELECT TABLE_SCHEMA, TABLE_NAME, TABLE_TYPE, ENGINE, ROW_FORMAT, TABLE_ROWS, DATA_LENGTH, TABLE_COMMENT
|
|
|
|
FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME = 't1';
|
|
|
|
|
2011-07-02 22:12:12 +02:00
|
|
|
DROP TABLE t1;
|
|
|
|
|
2010-11-30 18:20:56 +01:00
|
|
|
--echo #
|
|
|
|
--echo # Cleanup
|
|
|
|
--echo #
|
|
|
|
|
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
|