1
0
mirror of https://github.com/MariaDB/server.git synced 2025-08-29 00:08:14 +03:00
Commit Graph

192 Commits

Author SHA1 Message Date
Bjorn Munch
3d2eff9715 Bug #12844282 62075: MTR TESTS SHOULD NOT HAVE TO SAVE & RESET INNODB_FILE_FORMAT_CHECK
This is a redo for 5.5
  Added 'innodb_file_format_max' as variable to ignore change to.
  Tests that had to restore this amended
  Two tests assumed it to be Antelope, make sure these run on a freshly
    started server
2011-10-05 15:14:14 +02:00
kevin.lewis@oracle.com
0f359571c5 Bug 12963823 - Crash in Purge thread under unusual circumstances.
The problem occurred when indexes are added between the time that an
UNDO record is created and the time that the purge thread comes around
and deletes the old secondary index entries.  The purge thread would
hit an assert when trying to build a secondary index entry for
searching.  The problem was that the old value of those fields were not
in the UNDO record since they were not part of an index when the UPDATE
occured. 
A test case was added to innodb-index.test.
2011-09-20 18:17:36 -06:00
Marko Mäkelä
4c57188c9c Bug#12547647 UPDATE LOGGING COULD EXCEED LOG PAGE SIZE
This fix was accidentally pushed to mysql-5.1 after the 5.1.59 clone-off in
bzr revision id marko.makela@oracle.com-20110829081642-z0w992a0mrc62s6w
with the fix of Bug#12704861 Corruption after a crash during BLOB update
but not merged to mysql-5.5 and upwards.

In the Barracuda formats, the clustered index record no longer
contains a prefix of off-page columns. Because of this, the undo log
must contain these prefixes, so that purge and multi-versioning will
continue to work. However, this also means that an undo log record can
become too big to fit in an undo log page. (It is a limitation of the
undo log that undo records cannot span across multiple pages.)

In case the checks for undo log size fail when CREATE TABLE or CREATE
INDEX is executed, we need a fallback that blocks a modification
operation when the undo log record would exceed the maximum size.

trx_undo_free_last_page_func(): Renamed from trx_undo_free_page_in_rollback().
Define the trx_t parameter only in debug builds.

trx_undo_free_last_page(): Wrapper for trx_undo_free_last_page_func().
Pass the trx_t parameter only in debug builds.

trx_undo_truncate_end_func(): Renamed from trx_undo_truncate_end().
Define the trx_t parameter only in debug builds. Rewrite a for(;;) loop
as a while loop for clarity.

trx_undo_truncate_end(): Wrapper for from trx_undo_truncate_end_func().
Pass the trx_t parameter only in debug builds.

trx_undo_erase_page_end(): Return TRUE if the page was non-empty
to begin with. Refuse to erase empty pages.

trx_undo_report_row_operation(): If the page for which the undo log
was too big was empty, free the undo page and return DB_TOO_BIG_RECORD.

rb:749 approved by Inaam Rana
2011-09-01 21:48:04 +03:00
Jimmy Yang
28c784aa17 In innobase_format_name() we should call innobase_convert_name() with
"!is_index_name" instead of "is_index_name", so the table name in the
error message would not be formated as index name.
2011-08-17 02:39:55 -07:00
Jimmy Yang
177d8b0c12 Fix bug #11830883, SUPPORT "CORRUPTED" BIT FOR INNODB TABLES AND INDEXES.
Also addressed issues in bug #11745133, where we could mark a table
corrupted instead of crashing the server when found a corrupted buffer/page
if the table created with innodb_file_per_table on.
2011-08-16 18:07:59 -07:00
Marko Mäkelä
065f18630f Merge mysql-5.1 to mysql-5.5. Add a test case. 2011-08-15 12:18:34 +03:00
Marko Mäkelä
337d7935d9 Merge mysql-5.1 to mysql-5.5. 2011-08-08 12:16:15 +03:00
kevin.lewis@oracle.com
1f844faa4c Null Merge from mysql-5.1 with second fix for Bug#12637786
Bug#12637786 was fixed with rb:692 by marko.  But that fix has a remaining
bug.  It added this assert;
    ut_ad(ind_field->prefix_len);
before a section of code that assumes there is a prefix_len.  

The patch replaced code that explicitly avoided this with a check for
prefix_len.  It turns out that the purge thread can get to that assert
without a prefix_len because it does not use a row_ext_t* .
When UNIV_DEBUG is not defined, the affect of this is that the purge thread
sets the dfield->len to zero and then cannot find the entry in the index to
purge.  So secondary index entries remain unpurged.

This patch does not do the assert.  Instead, it uses
    'if (ind_field->prefix_len) {...}'
around the section of code that assumes a prefix_len.  This is the way the
patch I provided to Marko did it.

The test case is simply modified to do a sleep(10) in order to give the
purge thread a chance to run. Without the code change to row0row.c, this
modified testcase will assert if InnoDB was compiled with UNIV_DEBUG.
I tried to sleep(5), but it did not always assert.
2011-07-08 08:16:23 -05:00
hery.ramilison@oracle.com
c74d844de3 Merge from mysql-5.5.14-release 2011-07-06 01:13:50 +02:00
Georgi Kodinov
455c676792 merged mysql-5.5->mysql-5.5-security 2011-06-06 16:17:58 +03:00
Vinay Fisrekar
7825b6b890 Correcting "innodb_prefix_index_liftedlimit" failure for embedded mode run.
Separating out sub-test.
2011-06-02 15:12:55 +05:30
Vinay Fisrekar
a115291b95 Adding testcases for WL#5743 InnoDB: Lift the limit of index key prefixes
innodb_prefix_index_liftedlimit.test used for functional testing of increase in prefix index limit
2011-06-01 15:25:08 +05:30
Jimmy Yang
bd708b4240 Implement worklog #5743 InnoDB: Lift the limit of index key prefixes.
With this change, the index prefix column length lifted from 767 bytes
to 3072 bytes if "innodb_large_prefix" is set to "true".

rb://603 approved by Marko
2011-05-31 02:12:32 -07:00
Dmitry Lenev
c61e346f51 Fix for bug #11762012 - "54553: INNODB ASSERTS IN
HA_INNOBASE::UPDATE_ROW, TEMPORARY TABLE, TABLE LOCK".

Attempt to update an InnoDB temporary table under LOCK TABLES
led to assertion failure in both debug and production builds
if this temporary table was explicitly locked for READ. The
same scenario works fine for MyISAM temporary tables.

The assertion failure was caused by discrepancy between lock
that was requested on the rows of temporary table at LOCK TABLES
time and by update operation. Since SQL-layer requested a
read-lock at LOCK TABLES time InnoDB engine assumed that upcoming
statements which are going to be executed under LOCK TABLES will
only read table and therefore should acquire only S-lock.
An update operation broken this assumption by requesting X-lock.

Possible approaches to fixing this problem are:

1) Skip locking of temporary tables as locking doesn't make any
   sense for connection-local objects.
2) Prohibit changing of temporary table locked by LOCK TABLES ...
   READ.

Unfortunately both of these approaches have drawbacks which make
them unviable for stable versions of server.

So this patch takes another approach and changes code in such way
that LOCK TABLES for a temporary table will always request write
lock. In 5.5 version of this patch switch from read lock to write
lock is done on SQL-layer.
2011-05-26 19:50:06 +04:00
Dmitry Lenev
d076be2a32 Fix for bug #11762012 - "54553: INNODB ASSERTS IN
HA_INNOBASE::UPDATE_ROW, TEMPORARY TABLE, TABLE LOCK".

Attempt to update an InnoDB temporary table under LOCK TABLES
led to assertion failure in both debug and production builds
if this temporary table was explicitly locked for READ. The 
same scenario works fine for MyISAM temporary tables.

The assertion failure was caused by discrepancy between lock 
that was requested on the rows of temporary table at LOCK TABLES
time and by update operation. Since SQL-layer requested a 
read-lock at LOCK TABLES time InnoDB engine assumed that upcoming
statements which are going to be executed under LOCK TABLES will 
only read table and therefore should acquire only S-lock.
An update operation broken this assumption by requesting X-lock.

Possible approaches to fixing this problem are:

1) Skip locking of temporary tables as locking doesn't make any
   sense for connection-local objects.
2) Prohibit changing of temporary table locked by LOCK TABLES ... 
   READ.

Unfortunately both of these approaches have drawbacks which make 
them unviable for stable versions of server.

So this patch takes another approach and changes code in such way
that LOCK TABLES for a temporary table will always request write
lock. In 5.1 version of this patch switch from read lock to write
lock is done inside of InnoDBs handler methods as doing it on 
SQL-layer causes compatibility troubles with FLUSH TABLES WITH
READ LOCK.
2011-05-26 17:14:47 +04:00
Marko Mäkelä
1ab52ab7c7 Merge mysql-5.1-security to mysql-5.5-security. 2011-05-19 17:01:47 +03:00
Marko Mäkelä
13520f4ae5 Merge mysql-5.1 to mysql-5.5. 2011-06-30 13:23:34 +03:00
Marko Mäkelä
37282cc6bd Bug#12699505 Memory leak in row_create_index_for_mysql()
DB_COL_APPEARS_TWICE_IN_INDEX: Remove. This condition is already
checked and reported by MySQL before passing the index definition to
the storage engine.

row_create_index_for_mysql(): Remove the redundant check for
DB_COL_APPEARS_TWICE_IN_INDEX. When enforcing the column prefix index
limit, invoke dict_mem_index_free(index) to plug the memory leak. In
the loop, use index->n_def instead of dict_index_get_n_fields(index),
because the latter would be 0 for indexes that have not been copied to
the data dictionary cache.

innodb-use-sys-malloc.test:

Add test cases for attempting to trigger the error checks in
row_create_index_for_mysql(). Before MySQL 5.5 and WL#5743, the leak
is only reproducible if ha_innobase::max_supported_key_part_length()
returned a higher limit than the one used in
row_create_index_for_mysql().

In MySQL 5.5 and later, the leak is reproducible with
innodb_large_prefix=true.

rb:688 approved by Jimmy Yang
2011-06-28 15:28:21 +03:00
Marko Mäkelä
c9cc074113 Bug#11753728 45225: Locking: hang if drop table with no timeout
Fix a failure of the re-enabled innodb-index.test in the embedded server.
Apparently, the embedded server does not default to ENGINE=InnoDB when
copying an InnoDB table by CREATE TABLE t2 SELECT * FROM t1;
2011-06-23 12:40:19 +03:00
Marko Mäkelä
7769a22622 Bug#11753728 45225: Locking: hang if drop table with no timeout
Re-enable a test that was disabled as collateral damage.

Starting with MySQL 5.5, queries will acquire and hold a shared meta-data lock
(MDL) on tables they process, until the transaction is committed or
rolled back. This will prevent DDL operations on the tables, such as creating
an index.

innodb-index.test: Use a second table for creating the index. The index will
still be "too new" for the transaction that was started before the index
creation was started.
2011-06-22 11:20:19 +03:00
kevin.lewis@oracle.com
6593ca560b Bug#60309 - Bug#12356829: MYSQL 5.5.9 FOR MAC OSX HAS BUG WITH FOREIGN KEY CONSTRAINTS
The innoDB global variable srv_lower_case_table_names is set to the value of lower_case_table_names declared in mysqld.h server in ha_innodb.cc.  Since this variable can change at runtime, it is reset for each handler call to ::create, ::open, ::rename_table & ::delete_table.

But it is possible for tables to be implicitly opened before an explicit handler call is made when an engine is first started or restarted.  I was able to reproduce that with the testcase in this patch on a version of InnoDB from 2 weeks ago.  It seemed like the change buffer entries for the secondary key was getting put into pages after the restart.  (But I am not sure, I did not write down the call stack while it was reproducing.)  In the current code, the implicit open, which is actually a call to dict_load_foreigns(), does not occur with this testcase.

The change is to replace srv_lower_case_table_names by an interface function in innodb.cc that retrieves the server global variable when it is needed.
2011-04-26 12:55:52 -05:00
Marko Mäkelä
cdba023d9a Merge mysql-5.1-innodb to mysql-5.5-innodb. 2011-04-11 17:03:32 +03:00
Marko Mäkelä
1a0dde9206 Bug #11766513 - 59641: Prepared XA transaction in system after hard crash
causes future shutdown hang

InnoDB would hang on shutdown if any XA transactions exist in the
system in the PREPARED state. This has been masked by the fact that
MySQL would roll back any PREPARED transaction on shutdown, in the
spirit of Bug #12161 Xa recovery and client disconnection.

[mysql-test-run] do_shutdown_server: Interpret --shutdown_server 0 as
a request to kill the server immediately without initiating a
shutdown procedure.

xid_cache_insert(): Initialize XID_STATE::rm_error in order to avoid a
bogus error message on XA ROLLBACK of a recovered PREPARED transaction.

innobase_commit_by_xid(), innobase_rollback_by_xid(): Free the InnoDB
transaction object after rolling back a PREPARED transaction.

trx_get_trx_by_xid(): Only consider transactions whose
trx->is_prepared flag is set. The MySQL layer seems to prevent
attempts to roll back connected transactions that are in the PREPARED
state from another connection, but it is better to play it safe. The
is_prepared flag was introduced in the InnoDB Plugin.

trx_n_prepared: A new counter, counting the number of InnoDB
transactions in the PREPARED state.

logs_empty_and_mark_files_at_shutdown(): On shutdown, allow
trx_n_prepared transactions to exist in the system.

trx_undo_free_prepared(), trx_free_prepared(): New functions, to free
the memory objects of PREPARED transactions on shutdown. This is not
needed in the built-in InnoDB, because it would collect all allocated
memory on shutdown. The InnoDB Plugin needs this because of
innodb_use_sys_malloc.

trx_sys_close(): Invoke trx_free_prepared() on all remaining
transactions.
2011-04-07 21:12:54 +03:00
Vasil Dimov
e208984cf2 Merge mysql-5.1-innodb -> mysql-5.5-innodb 2011-04-05 11:30:38 +03:00
Vasil Dimov
619f684f54 Add the testcase for Bug#59410 to 5.1/builtin
Bug#59410 read uncommitted: unlock row could not find a 3 mode lock
on the record

This bug is present only in 5.6 but I am adding the test case to earlier
versions to ensure it never appears in earlier versions too.
2011-04-05 11:08:36 +03:00
kevin.lewis@oracle.com
4bd4f411c7 Bug#60196 / Bug#11831040
Test case cannot run on embedded server.
No need for precautionary cleanup of unique names.
2011-03-09 11:15:55 -06:00
kevin.lewis@oracle.com
d072bb0d7f Bug#60196 / Bug#11831040
Setting lowercase_table_names to 2 on Windows causing Foreign Key problems

This problem was exposed by the fix for Bug#55222.  There was a codepath in dict0load.c,
dict_load_foreigns() that made sure the table name matched case sensitive in order to
load a referenced table into the dictionary as needed.  If an engine is rebooted which
accesses a table with foreign keys, and lower_case_table_names=2, then the table with
foreign keys will get an error when it is changed (insert/updated/delete).
Once the referenced tables are loaded into the dictionary cache by a select statement
on those tables, the same change would succeed because the affected code path would
not get followed.
2011-03-07 09:42:07 -06:00
Vasil Dimov
60a8407231 Merge mysql-5.5-innodb -> mysql-5.5 2011-02-17 13:57:26 +02:00
Vasil Dimov
0a3e7beb1e Merge mysql-5.1-innodb -> mysql-5.1 2011-02-17 13:56:05 +02:00
Marko Mäkelä
cfc9176bce Merge mysql-5.1-innodb to mysql-5.5-innodb. 2011-02-15 12:18:15 +02:00
Marko Mäkelä
518a4440ea Add a test for suspected Bug#60049. 2011-02-15 12:12:27 +02:00
Marko Mäkelä
53cfea3911 Merge mysql-5.1-innodb to mysql-5.5-innodb. 2011-02-15 11:29:56 +02:00
Jimmy Yang
801d018411 Merge a fix for Bug #53756 ALTER TABLE ADD PRIMARY KEY affects crash recovery
This was already pushed to mysql-5.1-innodb some time ago
(revision id jimmy.yang@oracle.com-20100907054137-tpuior7hez4f5ghl)
but it was not merged to the 5.5 trees.
2011-02-10 00:58:23 -08:00
Dmitry Lenev
3473329d3b Fix for bug #58650 "Failing assertion: primary_key_no == -1 ||
primary_key_no == 0".

Attempt to create InnoDB table with non-nullable column of
geometry type having an unique key with length 12 on it and
with some other candidate key led to server crash due to
assertion failure in both non-debug and debug builds.

The problem was that such a non-candidate key could have
been sorted as the first key in table/.FRM, before any legit
candidate keys. This resulted in assertion failure in InnoDB
engine which assumes that primary key should either be the
first key in table/.FRM or should not exist at all.

The reason behind such an incorrect sorting was an wrong
value of Create_field::key_length member for geometry field
(which was set to its pack_length == 12) which confused code
in mysql_prepare_create_table(), so it would skip marking
such key as a key with partial segments.

This patch fixes the problem by ensuring that this member
gets the same value of Create_field::key_length member as 
for other blob fields (from which geometry field class is
inherited), and as result unique keys on geometry fields
are correctly marked as having partial segments.
2011-02-02 16:17:48 +03:00
Vasil Dimov
54002d0a49 Merge mysql-5.5 -> mysql-5.5-innodb 2011-01-24 09:42:07 +02:00
Jimmy Yang
c4c90d912a Merge from mysql-5.1-innodb to mysql-5.5-innodb 2011-01-14 23:24:47 -08:00
Jimmy Yang
669ce69483 Fix Bug#30423 "InnoDBs treatment of NULL in index stats causes bad
"rows examined" estimates". This change implements "innodb_stats_method"
with options of "nulls_equal", "nulls_unequal" and "null_ignored".
      
rb://553 approved by Marko
2011-01-14 09:02:28 -08:00
Jonathan Perkin
d06e324e66 Merge from mysql-5.5.9-release 2011-02-08 14:59:03 +01:00
Dmitry Lenev
3be9d7420e Merged fix for bug #58650 "Failing assertion:
primary_key_no == -1 || primary_key_no == 0"
into mysql-5.5 tree.
2011-02-02 16:53:56 +03:00
Georgi Kodinov
7fd0c36b7b merge 2011-01-10 15:09:57 +02:00
Vasil Dimov
1d3fd9d931 Merge mysql-5.5-innodb -> mysql-5.5 2011-01-08 17:00:48 +02:00
Matthias Leich
d09ed4e08c Fix for Bug#47745 innodb.innodb-timeout fails sporadically
- Second scenario checked:
  Ensure via wait routines that the commit comes after the
  processing of the statement which should get finally
  the ER_LOCK_WAIT_TIMEOUT
  --> This should prevent the current bug.
- First scenario checked:
  Ensure via wait routines that the statement is already waiting
  for getting the lock before the commit is given.
  --> No effect on the current bug, but ensure that the right
      scenario is reached.
- Take care that disconnects are finished before the test ends.
  --> Reduce the potential to harm succeeding tests.
- "Mangle" the printout of the current default innodb_lock_wait_timeout value
  --> No need to adjust the test in case the default gets changed in future.
2011-01-07 14:16:28 +01:00
Vasil Dimov
18e211279d Merge mysql-5.5-bugteam -> mysql-5.5-innodb 2010-12-27 19:24:05 +02:00
Marko Mäkelä
85d668b45c Merge mysql-5.1-innodb to mysql-5.5-innodb. 2010-12-21 14:05:10 +02:00
Georgi Kodinov
24a40d0b77 merge 2010-12-17 15:10:40 +02:00
Alexander Nozdrin
a72186103f Manual merge from mysql-5.5. 2010-12-16 21:43:21 +03:00
Sergey Glukhov
cd36a6a5d5 Fixed following problems:
--Bug#52157 various crashes and assertions with multi-table update, stored function
--Bug#54475 improper error handling causes cascading crashing failures in innodb/ndb
--Bug#57703 create view cause Assertion failed: 0, file .\item_subselect.cc, line 846
--Bug#57352 valgrind warnings when creating view
--Recently discovered problem when a nested materialized derived table is used
  before being populated and it leads to incorrect result

We have several modes when we should disable subquery evaluation.
The reasons for disabling are different. It could be
uselessness of the evaluation as in case of 'CREATE VIEW'
or 'PREPARE stmt', or we should disable subquery evaluation
if tables are not locked yet as it happens in bug#54475, or
too early evaluation of subqueries can lead to wrong result
as it happened in Bug#19077.
Main problem is that if subquery items are treated as const
they are evaluated in ::fix_fields(), ::fix_length_and_dec()
of the parental items as a lot of these methods have
Item::val_...() calls inside.
We have to make subqueries non-const to prevent unnecessary
subquery evaluation. At the moment we have different methods
for this. Here is a list of these modes:

1. PREPARE stmt;
We use UNCACHEABLE_PREPARE flag.
It is set during parsing in sql_parse.cc, mysql_new_select() for
each SELECT_LEX object and cleared at the end of PREPARE in
sql_prepare.cc, init_stmt_after_parse(). If this flag is set
subquery becomes non-const and evaluation does not happen.

2. CREATE|ALTER VIEW, SHOW CREATE VIEW, I_S tables which
   process FRM files
We use LEX::view_prepare_mode field. We set it before
view preparation and check this flag in
::fix_fields(), ::fix_length_and_dec().
Some bugs are fixed using this approach,
some are not(Bug#57352, Bug#57703). The problem here is
that we have a lot of ::fix_fields(), ::fix_length_and_dec()
where we use Item::val_...() calls for const items.

3. Derived tables with subquery = wrong result(Bug19077)
The reason of this bug is too early subquery evaluation.
It was fixed by adding Item::with_subselect field
The check of this field in appropriate places prevents
const item evaluation if the item have subquery.
The fix for Bug19077 fixes only the problem with
convert_constant_item() function and does not cover
other places(::fix_fields(), ::fix_length_and_dec() again)
where subqueries could be evaluated.

Example:
CREATE TABLE t1 (i INT, j BIGINT);
INSERT INTO t1 VALUES (1, 2), (2, 2), (3, 2);
SELECT * FROM (SELECT MIN(i) FROM t1
WHERE j = SUBSTRING('12', (SELECT * FROM (SELECT MIN(j) FROM t1) t2))) t3;
DROP TABLE t1;

4. Derived tables with subquery where subquery
   is evaluated before table locking(Bug#54475, Bug#52157)

Suggested solution is following:

-Introduce new field LEX::context_analysis_only with the following
 possible flags:
 #define CONTEXT_ANALYSIS_ONLY_PREPARE 1
 #define CONTEXT_ANALYSIS_ONLY_VIEW    2
 #define CONTEXT_ANALYSIS_ONLY_DERIVED 4
-Set/clean these flags when we perform
 context analysis operation
-Item_subselect::const_item() returns
 result depending on LEX::context_analysis_only.
 If context_analysis_only is set then we return
 FALSE that means that subquery is non-const.
 As all subquery types are wrapped by Item_subselect
 it allow as to make subquery non-const when
 it's necessary.
2010-12-14 12:33:03 +03:00
Sergey Glukhov
0e77c3295a Bug#39828 : Autoinc wraps around when offset and increment > 1
Auto increment value wraps when performing a bulk insert with
auto_increment_increment and auto_increment_offset greater than
one.
The fix:
If overflow happened then return MAX_ULONGLONG value as an
indication of overflow and check this before storing the
value into the field in update_auto_increment().
2010-12-13 14:48:12 +03:00
Sergey Glukhov
a2aa73d92a 5.1-bugteam->5.5-bugteam merge 2010-12-14 13:46:00 +03:00
Sergey Glukhov
92c303ced6 5.1-bugteam->5.5-bugteam merge 2010-12-13 15:11:16 +03:00