Commit graph

740 commits

Author SHA1 Message Date
Jan Lindström
ef92aaf9ec MDEV-10083: Orphan ibd file when playing with foreign keys
Analysis: row_drop_table_for_mysql did not allow dropping
referenced table even in case when actual creating of the
referenced table was not successfull if foreign_key_checks=1.

Fix: Allow dropping referenced table even if foreign_key_checks=1
if actual table create returned error.
2016-06-23 06:46:05 +03:00
Jan Lindström
0f252702b1 MDEV-7139: Sporadic failure in innodb.innodb_corrupt_bit on P8
Use direct persistent index corruption set on InnoDB dictionary
for this test. Do not allow creating new indexes if one of the
existing indexes is already marked as corrupted.
2016-06-08 08:40:10 +03:00
Jan Lindström
19e3597e0c MDEV-9142 :Adding Constraint with no database reference
results in ERROR 1046 (3D000) at line 13: No database selected.

Use database from create table to foreign key database if
nothing else is given.
2016-04-23 13:05:15 +03:00
Jan Lindström
c19972fc87 MDEV-9251: Fix MySQL Bug#20755615: InnoDB compares column names case sensitively,
while according to Storage Engine API column names should be compared
case insensitively. This can cause FRM and InnoDB data dictionary to
go out of sync.
2015-12-11 14:33:41 +02:00
Sergei Golubchik
abf9d35213 Merge branch 'mysql/5.5' into 5.5 2015-12-09 10:00:49 +01:00
Sergei Golubchik
ef47b62551 MDEV-8827 Duplicate key with auto increment
fix innodb auto-increment handling
three bugs:
1. innobase_next_autoinc treated the case of current<offset incorrectly
2. ha_innobase::get_auto_increment didn't recalculate current when increment changed
3. ha_innobase::get_auto_increment didn't pass offset down to innobase_next_autoinc
2015-12-07 15:20:23 +01:00
Sergei Golubchik
c8652eefe5 one more test 2015-12-07 15:20:22 +01:00
Jan Lindström
33589b25ef MDEV-7762 InnoDB: Failing assertion: block->page.buf_fix_count > 0 in buf0buf.ic line 730
Analysis: debug only assertion I_S function (IS is XtraDB feature) is calling
buf_block_get_frame on any page it reads, which debug-asserts that the page is
buffer-fixed, which is not the case in I_S query.

Fixed by holding the buffer page mutex while the fields are read directly.
2015-12-03 13:18:10 +02:00
Jan Lindström
5d754fce95 MDEV-8854: New warning messages are unreadable
Improved warning messages by quote marks.
2015-11-09 09:24:52 +02:00
Jan Lindström
006acf7454 Bug : drop index on a foreign key column leads to missing table
MDEV-8845: Table disappear after modifying FK

Added test case.
2015-09-30 10:49:45 +03:00
Annamalai Gurusami
8ea80ecfeb Bug DROP DATABASE HANGS WITH MALFORMED TABLE
Note: Backporting the patch from mysql-5.6.

Problem:

A CREATE TABLE with an invalid table name is detected
at SQL layer. So the table name is reset to an empty
string.  But the storage engine is called with this
empty table name.  The table name is specified as
"database/table".  So, in the given scenario we get
only "database/".

Solution:

Within InnoDB, detect this error and report it to
higher layer.

rb#9274 approved by jimmy.
2015-09-22 06:21:13 +02:00
Sergei Golubchik
6300f2f274 Merge tag 'mysql-5.5.45' into 5.5 2015-08-01 14:56:18 +02:00
Jan Lindström
fa765a4525 MDEV-6697: Improve foreign keys warnings/errors
There is several different ways to incorrectly define
foreign key constraint. In many cases earlier MariaDB
versions the error messages produced by these cases
are not very clear and helpful. This patch improves
the warning messages produced by foreign key parsing.
2015-07-31 08:59:13 +03:00
Jan Lindström
e05cd97b8a MDEV-8524: Improve error messaging when there is duplicate key or foreign key names
Added better error message that will be printed when foreign key
constraint name in create table is not unique in database.
2015-07-31 08:59:13 +03:00
Jan Lindström
7a9670218b MDEV-8474: InnoDB sets per-connection data unsafely
Analysis: At check_trx_exists function InnoDB allocates
a new trx if no trx is found from thd but this newly
allocated trx is not registered to thd. This is unsafe,
because nothing prevents InnoDB plugin from being uninstalled
while there's active transaction. This can cause crashes, hang
and any other odd behavior. It may also corrupt stack, as
functions pointers are not available after dlclose.

Fix: The fix is to use thd_set_ha_data() when
manipulating per-connection handler data. It does appropriate
plugin locking.
2015-07-21 12:12:58 +03:00
Annamalai Gurusami
db2ed27e0e Bug FK DDL: CRASH IN DICT_FOREIGN_REMOVE_FROM_CACHE
Problem:

If we add a referential integrity constraint with a duplicate
name, an error occurs.  The foreign key object would not have
been added to the dictionary cache.  In the error path, there
is an attempt to remove this foreign key object. Since this
object is not there, the search returns a NULL result.
De-referencing the null object results in this crash.

Solution:

If the search to the foreign key object failed, then don't
attempt to access it.

rb#9309 approved by Marko.
2015-06-19 10:17:52 +05:30
Sergei Golubchik
f84f577aa1 Merge tag 'mysql-5.5.44' into bb-5.5-serg 2015-06-05 02:06:51 +02:00
Jan Lindström
4c174fcb4a MDEV-8020: innodb.innodb-mdev-7055 produces valgrind warnings in buildbot
Fixed by reverting incorrect fix of MDEC-7055 (reopened) and removing the
test case (because it now crashes).
2015-04-28 15:29:46 +03:00
Marko Mäkelä
25323de2a4 Bug#20816223 InnoDB crash on shutdown
if XA PREPARE transactions hold explicit locks.

innobase_shutdown_for_mysql(): Call trx_sys_close() before lock_sys_close()
(and dict_close()) so that trx_free_prepared() will see all locks intact.

RB: 8561
Reviewed-by: Vasil Dimov <vasil.dimov@oracle.com>
2015-04-09 08:13:07 +03:00
Jan Lindström
206b111b11 MDEV-7672: Crash creating an InnoDB table with foreign keys
Analysis: after a red-black-tree lookup we use node withouth
checking did lookup succeed or not. This lead to situation
where NULL-pointer was used.

Fix: Add additional check that found node from red-back-tree
is valid.
2015-03-06 11:19:23 +02:00
Kristian Nielsen
b5d6aa5517 MDEV-7310: last_commit_pos_offset set to wrong value after binlog rotate in group commit
When the binlog was rotated due to @@max_binlog_size, the values of the
binlog_shapshot_file and binlog_snapshot_position were inconsistent in case of
non-transactional DML. The position was refering to the old file, while the
filename was of the new file after rotation. This patch makes them consistent
by making sure the position is also refering to the new file.
2015-02-23 13:27:51 +01:00
Jan Lindström
552f1b3505 Fix test failures on innodb-mdev-7055 and innodb-mdev-7513. 2015-02-10 14:17:23 +02:00
Jan Lindström
ada07435b4 Fix test failure on innodb-mdev-7055. 2015-02-10 08:08:59 +02:00
Jan Lindström
5c6eb5222e Fix test failure. 2015-02-04 16:50:29 +02:00
Jan Lindström
422ffe99b5 InnoDB and XtraDB produce different output on MDEV-7513. 2015-02-04 11:12:46 +02:00
Jan Lindström
f32091532d MDEV-7055: MySQL#74664 - InnoDB: Failing assertion: len <= col->len || col->mtype == 5 || (col->len == 0 && col->mtype == 1) in file rem0rec.cc line 845
Debug assertion maybe too strict.
2015-02-04 10:50:16 +02:00
Jan Lindström
7afbf338aa MDEV-7513: ib_warn_row_too_big dereferences null thd
Analysis: Purge thread does not have thd and no access to
handlerton.

Fix: If thd does not exists we use sql_print_warning instead
of push_warning_printf.
2015-02-04 09:29:54 +02:00
Sergei Golubchik
5900333aa5 MDEV-7404 REPAIR multiple tables crash in MDL_ticket::has_stronger_or_equal_type
mysql_alter_table() that is used in mysql_recreate_table() doesn't expect
many tables in the TABLE_LIST.
2015-01-14 12:10:13 +01:00
Thiru
e7391e472e Bug TIS620: CRASH WITH MULTI TABLE DELETE
- Moving the test case to correct place.
2014-12-22 13:33:48 +05:30
Sergei Golubchik
a978bdda1e mysql-5.5.41 merge 2014-12-19 11:35:44 +01:00
Jan Lindström
e5802c38f9 Better comments and add a test case. 2014-11-25 08:06:41 +02:00
Thirunarayanan B
821dfcd8d2 Bug TIS620: CRASH WITH MULTI TABLE DELETE
Description:
  Using correct length when moving to next field in cmp_ref. The store
length already includes the length bytes of blobs, which is already considered
earlier for blob types.
	Approved by Mattias, Jimmy [rb-7088]
2014-11-04 17:40:29 +05:30
Marko Makela
a265914018 Bug#19904003 INNODB_LIMIT_OPTIMISTIC_INSERT_DEBUG=1 CAUSES INFINITE PAGE SPLIT
The debug configuration parameter innodb_optimistic_insert_debug
which was introduced for testing corner cases in B-tree handling
had a bug in it. The value 1 would trigger an infinite sequence
of page splits.

Fix: When the value 1 is specified, disable this debug feature.
Approved by Yasufumi Kinoshita
2014-10-30 08:53:46 +02:00
Marko Makela
ff906f032f Bug#19904003 INNODB_LIMIT_OPTIMISTIC_INSERT_DEBUG=1 CAUSES INFINITE PAGE SPLIT
The debug configuration parameter innodb_optimistic_insert_debug
which was introduced for testing corner cases in B-tree handling
had a bug in it. The value 1 would trigger an infinite sequence
of page splits.

Fix: When the value 1 is specified, disable this debug feature.
Approved by Yasufumi Kinoshita
2014-10-30 08:53:46 +02:00
Marko Makela
c978f6988d Bug#19584379 Reporting corruption may corrupt the innodb data dictionary
dict_set_corrupted(): Use the canonical way of searching for
less-than-equal (PAGE_CUR_LE) and then checking low_match.

The code that was introduced in MySQL 5.5.17 in
    Bug#11830883 SUPPORT "CORRUPTED" BIT FOR INNODB TABLES AND INDEXES
could position the cursor on the page supremum, and then attempt
to overwrite non-existing 7th field of the 1-field supremum record.

Approved by Jimmy Yang
2014-10-27 14:27:08 +02:00
Marko Makela
352b6bc9a8 Bug#19584379 Reporting corruption may corrupt the innodb data dictionary
dict_set_corrupted(): Use the canonical way of searching for
less-than-equal (PAGE_CUR_LE) and then checking low_match.

The code that was introduced in MySQL 5.5.17 in
    Bug#11830883 SUPPORT "CORRUPTED" BIT FOR INNODB TABLES AND INDEXES
could position the cursor on the page supremum, and then attempt
to overwrite non-existing 7th field of the 1-field supremum record.

Approved by Jimmy Yang
2014-10-27 14:27:08 +02:00
Annamalai Gurusami
5c41d52904 The test case innodb.foreign-keys is failing in pb2 5.5. This is because
some of the tables are created in InnoDB and some tables are created in MyISAM.
We need to create all tables on InnoDB.  Fix is to add engine=innodb to the
CREATE TABLE statements.  

approved in IM by Marko and Vasil.
2014-10-20 15:43:28 +05:30
Annamalai Gurusami
a6ed922e8c The test case innodb.foreign-keys is failing in pb2 5.5. This is because
some of the tables are created in InnoDB and some tables are created in MyISAM.
We need to create all tables on InnoDB.  Fix is to add engine=innodb to the
CREATE TABLE statements.  

approved in IM by Marko and Vasil.
2014-10-20 15:43:28 +05:30
Sergei Golubchik
7989c62bc0 post-merge fixes 2014-10-07 10:53:06 +02:00
Sergei Golubchik
1ddfce4840 mysql-5.5.40 2014-10-06 19:53:55 +02:00
unknown
0e5fe8e412 Merge from mysql-5.5.40-release 2014-09-23 08:51:23 +02:00
murthy.narkedimilli@oracle.com
abb9945965 Merge from mysql-5.5.40-release 2014-09-23 08:51:23 +02:00
Annamalai Gurusami
b8c9d93bf3 Bug FAILING ASSERTION WITH TEMP TABLE FOR A PROCEDURE CALLED
FROM A FUNCTION

Scenario:

In a stored procedure, CREATE TABLE statement is not allowed.  But an
exception is provided for CREATE TEMPORARY TABLE.  We can create a temporary
table in a stored procedure.

Let there be two stored functions f1 and f2 and two stored procedures p1 and
p2.  Their properties are as follows:

. stored function f1() calls stored procedure p1().
. stored function f2() calls stored procedure p2().
. stored procedure p1() creates temporary table t1.
. stored procedure p2() does DML on t1.

Consider the following situation:

1.  Autocommit mode is on. 
2.  select f1()
3.  select f2()

Step 2:  In this step, t1 would be created via p1().  A table level transaction
lock would have been taken.  The ::external_lock() would not have been called
on this table.  At the end of step 2, because of autocommit mode on, this table
level lock will be released.

Step 3:  When we execute DML on table t1 via p2() we have two problems:

Problem 1:

The function ha_innobase::external_lock() would have been called but since
it is a select query no table level locks would have been taken.  Hence the
following assert will fail:

ut_ad(lock_table_has(thr_get_trx(thr), index->table, LOCK_IX));

Solution:

The solution would be to identify this situation and take a table level lock
and use the proper lock type prebuilt->select_lock_type = LOCK_X for DML
operations.

Problem 2:

Another problem is that in step 3, ha_innobase::open() is never called on
the table t1.  

Solution:

The solution would be to identify this situation and call re-init the handler
of table t1.

rb#6429 approved by Krunal.
2014-09-18 15:17:39 +05:30
Annamalai Gurusami
db78f29b31 Bug FAILING ASSERTION WITH TEMP TABLE FOR A PROCEDURE CALLED
FROM A FUNCTION

Scenario:

In a stored procedure, CREATE TABLE statement is not allowed.  But an
exception is provided for CREATE TEMPORARY TABLE.  We can create a temporary
table in a stored procedure.

Let there be two stored functions f1 and f2 and two stored procedures p1 and
p2.  Their properties are as follows:

. stored function f1() calls stored procedure p1().
. stored function f2() calls stored procedure p2().
. stored procedure p1() creates temporary table t1.
. stored procedure p2() does DML on t1.

Consider the following situation:

1.  Autocommit mode is on. 
2.  select f1()
3.  select f2()

Step 2:  In this step, t1 would be created via p1().  A table level transaction
lock would have been taken.  The ::external_lock() would not have been called
on this table.  At the end of step 2, because of autocommit mode on, this table
level lock will be released.

Step 3:  When we execute DML on table t1 via p2() we have two problems:

Problem 1:

The function ha_innobase::external_lock() would have been called but since
it is a select query no table level locks would have been taken.  Hence the
following assert will fail:

ut_ad(lock_table_has(thr_get_trx(thr), index->table, LOCK_IX));

Solution:

The solution would be to identify this situation and take a table level lock
and use the proper lock type prebuilt->select_lock_type = LOCK_X for DML
operations.

Problem 2:

Another problem is that in step 3, ha_innobase::open() is never called on
the table t1.  

Solution:

The solution would be to identify this situation and call re-init the handler
of table t1.

rb#6429 approved by Krunal.
2014-09-18 15:17:39 +05:30
Annamalai Gurusami
40f30ee6cc Bug PRINT A WARNING WHEN DDL HAS AN ERROR IN INNODB_STRICT_MODE = 1
Problem:

Creation of a table fails when innodb_strict_mode is enabled, but the same
table is created without any warning when innodb_strict_mode is enabled.

Solution:

If creation of a table fails with an error when innodb_strict_mode is
enabled, it must issue a warning when innodb_strict_mode is disabled.

rb#6723 approved by Krunal.
2014-09-17 10:42:31 +05:30
Annamalai Gurusami
44fd241a22 Bug PRINT A WARNING WHEN DDL HAS AN ERROR IN INNODB_STRICT_MODE = 1
Problem:

Creation of a table fails when innodb_strict_mode is enabled, but the same
table is created without any warning when innodb_strict_mode is enabled.

Solution:

If creation of a table fails with an error when innodb_strict_mode is
enabled, it must issue a warning when innodb_strict_mode is disabled.

rb#6723 approved by Krunal.
2014-09-17 10:42:31 +05:30
Murthy Narkedimilli
3139aa87b4 Adding patch for security bug 19471516 2014-09-08 11:33:55 +02:00
Murthy Narkedimilli
a2375bdbe0 Adding patch for security bug 19471516 2014-09-08 11:33:55 +02:00
Jan Lindström
454037b794 MDEV-6682 innodb.innodb_simulate_comp_failures_small is too slow
if it's run on a real disk
  
  Made test smaller.
2014-09-03 07:37:13 +03:00
Annamalai Gurusami
2f8bd757cd Bug SERVER CRASHES WHEN EXECUTING ALTER TABLE ADD FOREIGN KEY
Problem:

We maintain two rb trees in each dict_table_t.  The foreign_rbt must be in
sync with foreign_list.  The referenced_rbt must be in sync with
referenced_list. There is one function which checks this consistency and it
failed, resulting in an assert failure.

The root cause of the problem was identified that the search order was 
lost in the referenced_rbt.  This is because while renaming the table,
we didn't not refresh this referenced_rbt.

Solution:

When a foreign key is renamed, we must delete and re-insert into both
foreign_rbt and referenced_rbt.  

rb#6412 approved by Jimmy.
2014-08-25 16:25:07 +02:00