Commit graph

304 commits

Author SHA1 Message Date
Sergei Golubchik
ab83952f29 10.0-base merge 2013-01-31 09:48:19 +01:00
Sergei Golubchik
d3935adf7a mysql-5.5.29 merge 2013-01-15 19:13:32 +01:00
Sergei Golubchik
aca8e7ed6b 5.3 merge 2013-01-15 19:07:46 +01:00
Sergei Golubchik
40e94a3734 merge with 5.5 2012-11-03 12:28:51 +01:00
Sergei Golubchik
bba8b263c2 restore the lost (in mysql-5.6) bugfix for
Bug#13510739 63775: SERVER CRASH ON HANDLER READ NEXT AFTER DELETE RECORD.
2012-10-28 10:00:32 +01:00
Sergei Golubchik
e1f681c99b 10.0-base -> 10.0-monty 2012-10-19 20:38:59 +02:00
Marko Mäkelä
f9389d584d Merge mysql-5.1 to mysql-5.5. 2012-10-18 17:14:57 +03:00
Marko Mäkelä
52ea152294 Bug#14758405: ALTER TABLE: ADDING SERIAL NULL DATATYPE: ASSERTION:
LEN <= SIZEOF(ULONGLONG)

This bug was caught in the WL#6255 ALTER TABLE...ADD COLUMN in MySQL
5.6, but there is a bug in all InnoDB versions that support
auto-increment columns.

row_search_autoinc_read_column(): When reading the maximum value of
the auto-increment column, and the column only contains NULL values,
return 0. This corresponds to the case when the table is empty in
row_search_max_autoinc().

rb:1415 approved by Sunny Bains
2012-10-18 17:03:06 +03:00
Sergei Golubchik
ee9afef271 mysql-5.5.28 2012-10-16 13:04:42 +02:00
Krunal Bauskar krunal.bauskar@oracle.com
ed6732dd16 bug#14704286
SECONDARY INDEX UPDATES MAKE CONSISTENT READS DO O(N^2) UNDO PAGE
LOOKUPS (honoring kill query while accessing sec_index)

If secondary index is being used for select query evaluation and this
query is operating with consistent read snapshot it might take good time for
secondary index to return back control to mysql as MVCC would kick in.

If user issues "kill query <id>" while query is actively accessing
secondary index it will not be honored as there is no hook to check
for this condition. Added hook for this check.

-----
Parallely secondary index taking too long to evaluate for consistent
read snapshot case is being examined for performance improvement. WL#6540.
2012-10-15 09:49:50 +05:30
Krunal Bauskar krunal.bauskar@oracle.com
9bfc910f2f bug#14704286
SECONDARY INDEX UPDATES MAKE CONSISTENT READS DO O(N^2) UNDO PAGE
LOOKUPS (honoring kill query while accessing sec_index)

If secondary index is being used for select query evaluation and this
query is operating with consistent read snapshot it might take good time for
secondary index to return back control to mysql as MVCC would kick in.

If user issues "kill query <id>" while query is actively accessing
secondary index it will not be honored as there is no hook to check
for this condition. Added hook for this check.

-----
Parallely secondary index taking too long to evaluate for consistent
read snapshot case is being examined for performance improvement. WL#6540.
2012-10-15 09:24:33 +05:30
Vasil Dimov
61bd7d0ce9 Merge mysql-5.1 -> mysql-5.5 2012-10-09 16:41:13 +03:00
Annamalai Gurusami
b59a64e2f3 Bug #13249921 ASSERT !BPAGE->FILE_PAGE_WAS_FREED, USUALLY IN
TRANSACTION ROLLBACK

Description:  During the rollback operation, a blob page 
is removed earlier than desired.  Consider following scenario:

1. create table t1(a int primary key,b blob) engine=innodb;
2. insert into t1 values (1,repeat('b',9000));
3. begin;
4. update t1 set b=concat(b,'b');
5. update t1 set a=a+1;
6. insert into t1 values (1,repeat('b',9000));
7. rollback;

The update operation in line 5 produces 2 undo log record. The first
undo record (TRX_UNDO_DEL_MARK_REC) goes to trx->update_undo and the
second undo record (TRX_UNDO_INSERT_REC) goes to trx->insert_undo.
During rollback, they are executed out of order.

When the undo record TRX_UNDO_DEL_MARK_REC is applied/executed,
the blob ownership is also reset.  Because of this the blob page
is released earlier than desired.  This blob page must have been
freed only as part of applying/executing the undo record
TRX_UNDO_INSERT_REC.

This problem can be avoided by executing the undo records in
order.  This patch will make innodb to execute the undo records
in order.

rb://1125 approved by Marko.
2012-09-28 16:02:58 +05:30
Sergei Golubchik
474fe6d9d9 fixes for test failures
and small collateral changes

mysql-test/lib/My/Test.pm:
  somehow with "print" we get truncated writes sometimes
mysql-test/suite/perfschema/r/digest_table_full.result:
  md5 hashes of statement digests differ, because yacc token codes are different in mariadb
mysql-test/suite/perfschema/r/dml_handler.result:
  host table is not ported over yet
mysql-test/suite/perfschema/r/information_schema.result:
  host table is not ported over yet
mysql-test/suite/perfschema/r/nesting.result:
  this differs, because we don't rewrite general log queries, and multi-statement
  packets are logged as a one entry. this result file is identical to what mysql-5.6.5
  produces with the --log-raw option.
mysql-test/suite/perfschema/r/relaylog.result:
  MariaDB modifies the binlog index file directly, while MySQL 5.6 has a feature "crash-safe binlog index" and modifies a special "crash-safe" shadow copy of the index file and then moves it over. That's why this test shows "NONE" index file writes in MySQL and "MANY" in MariaDB.
mysql-test/suite/perfschema/r/server_init.result:
  MariaDB initializes the "manager" resources from the "manager" thread, and starts this thread only when --flush-time is not 0. MySQL 5.6 initializes "manager" resources unconditionally on server startup.
mysql-test/suite/perfschema/r/stage_mdl_global.result:
  this differs, because MariaDB disables query cache when query_cache_size=0. MySQL does not
  do that, and this causes useless mutex locks and waits.
mysql-test/suite/perfschema/r/statement_digest.result:
  md5 hashes of statement digests differ, because yacc token codes are different in mariadb
mysql-test/suite/perfschema/r/statement_digest_consumers.result:
  md5 hashes of statement digests differ, because yacc token codes are different in mariadb
mysql-test/suite/perfschema/r/statement_digest_long_query.result:
  md5 hashes of statement digests differ, because yacc token codes are different in mariadb
mysql-test/suite/rpl/r/rpl_mixed_drop_create_temp_table.result:
  will be updated to match 5.6 when alfranio.correia@oracle.com-20110512172919-c1b5kmum4h52g0ni and anders.song@greatopensource.com-20110105052107-zoab0bsf5a6xxk2y are merged
mysql-test/suite/rpl/r/rpl_non_direct_mixed_mixing_engines.result:
  will be updated to match 5.6 when anders.song@greatopensource.com-20110105052107-zoab0bsf5a6xxk2y is merged
2012-09-27 20:09:46 +02:00
Annamalai Gurusami
356c42d2c2 Merge from mysql-5.1 to mysql-5.5. 2012-09-28 16:42:31 +05:30
Annamalai Gurusami
9d41d7c57b Bug #14500557 CRASH WHEN USING LONG INNODB INDEXES
The ha_innobase table handler contained two search key buffers
(srch_key_val1, srch_key_val2) of fixed size used to store the search
key.  The size of these buffers where fixed at
REC_VERSION_56_MAX_INDEX_COL_LEN + 2.  But this size is not sufficient
to hold the search key.  Hence the following assert in
row_sel_convert_mysql_key_to_innobase() failed.

2438                 /* Storing may use at most data_len bytes of buf */
2439 
2440                 if (UNIV_LIKELY(!is_null)) {
2441                         ut_a(buf + data_len <= original_buf + buf_len);
2442                         row_mysql_store_col_in_innobase_format(
2443                                 dfield, buf,
2444                                 FALSE, /* MySQL key value format col */
2445                                 key_ptr + data_offset, data_len,
2446                                 dict_table_is_comp(index->table));
2447                         buf += data_len;
2448                 }

The buffer size is now calculated with the formula
MAX_KEY_LENGTH + MAX_REF_PARTS*2.  This properly takes into account
the extra bytes needed to store the length for each column.  An index
can contain a maximum of MAX_REF_PARTS columns in it, and for each
column 2 bytes are needed to store length.  

rb://1238 approved by Marko and Vasil Dimov.
2012-09-04 14:33:56 +05:30
Marko Mäkelä
b252933551 Merge mysql-5.1 to mysql-5.5. 2012-08-21 10:59:11 +03:00
Sergei Golubchik
d11829654c merge with MySQL 5.5.27
manually checked every change, reverted incorrect or stupid changes.
2012-08-09 17:22:00 +02:00
Marko Mäkelä
05c6614d01 Merge mysql-5.1 to mysql-5.5. 2012-08-09 10:06:59 +03:00
Michael Widenius
1d0f70c2f8 Temporary commit of merge of MariaDB 10.0-base and MySQL 5.6 2012-08-01 17:27:34 +03:00
Inaam Rana
b91be27733 merge from 5.1 2012-05-24 12:44:27 -04:00
Marko Mäkelä
a6da754a31 Merge mysql-5.1 to mysql-5.5. 2012-05-15 15:11:34 +03:00
Sergei Golubchik
431e042b5d c 2012-05-21 15:30:25 +02:00
Sunanda Menon
074ce71e90 Merge from mysql-5.1.63-release 2012-05-08 07:19:14 +02:00
Yasufumi Kinoshita
08e7444e54 Bug#11758510 (#50723): INNODB CHECK TABLE FATAL SEMAPHORE WAIT TIMEOUT POSSIBLY TOO SHORT FOR BI
Fixed not to check timeout during the check table.
2012-04-27 19:38:13 +09:00
Georgi Kodinov
7fa28bcf56 merge mysql-5.5->mysql-5.5-security 2012-04-10 14:23:17 +03:00
Sergei Golubchik
16c5c53fc2 mysql 5.5.23 merge 2012-04-10 08:28:13 +02:00
Sergei Golubchik
20e706689d mysql-5.5.22 merge
mysql-test/suite/innodb/t/group_commit_crash.test:
  remove autoincrement to avoid rbr being used for insert ... select
mysql-test/suite/innodb/t/group_commit_crash_no_optimize_thread.test:
  remove autoincrement to avoid rbr being used for insert ... select
mysys/my_addr_resolve.c:
  a pointer to a buffer is returned to the caller -> the buffer cannot be on the stack
mysys/stacktrace.c:
  my_vsnprintf() is ok here, in 5.5
2012-03-28 01:04:46 +02:00
Inaam Rana
5352a76134 Bug#13704145: ELIMINATE LRU SCAN WHEN DROPPING A TABLE
rb://942
approved by: Marko Makela

We don't need to scan LRU for dropping AHI entries when DROPing a table.
AHI entries are already removed when we free up extents for the btree.
2012-03-26 09:45:01 -04:00
Georgi Kodinov
5bf1a28915 merge mysql-5.5->mysql-5.5-security 2012-03-21 14:56:29 +02:00
Joerg Bruehe
747fbf8f8b Merge the 5.5.22 release build into main 5.5,
conflict in "sql/filesort.cc" solved manually.
2012-03-20 22:27:49 +01:00
Jimmy Yang
7f4d66d4cf Fix Bug #13860722 - INCOMPLETE PERFORMANCE SCHEMA INSTRUMENTATION IN INNODB 2012-03-20 17:44:51 +08:00
Sergei Golubchik
4933d21e5d merge with mysql-5.5.21 2012-03-09 08:06:59 +01:00
Georgi Kodinov
9c366f7921 merge mysql-5.5->mysql-5.5-security 2012-03-08 17:19:54 +02:00
Annamalai Gurusami
7e36c4bdb0 Bug#13635833: MULTIPLE CRASHES IN FOREIGN KEY CODE WITH CONCURRENT DDL/DML
There are two threads.  In one thread, dml operation is going on 
involving cascaded update operation.  In another thread, alter 
table add foreign key constraint is happening.  Under these 
circumstances, it is possible for the dml thread to access a 
dict_foreign_t object that has been freed by the ddl thread.  
The debug sync test case provides the sequence of operations.  
Without fix, the test case will crash the server (because of 
newly added assert).  With fix, the alter table stmt will return 
an error message.  
      
Backporting the fix from MySQL 5.5 to 5.1

rb:961
rb:947
2012-03-01 11:05:51 +05:30
Marko Mäkelä
2367e79e4c Merge mysql-5.1 to mysql-5.5. 2012-02-28 21:43:08 +02:00
Marko Mäkelä
8235c4e161 Merge mysql-5.1 to mysql-5.5. 2012-02-28 14:04:21 +02:00
Marko Mäkelä
a44974abdc Merge mysql-5.1 to mysql-5.5. 2012-02-27 23:24:36 +02:00
Annamalai Gurusami
c1615df32c Bug#13635833: MULTIPLE CRASHES IN FOREIGN KEY CODE WITH CONCURRENT DDL/DML
There are two threads.  In one thread, dml operation is going on 
involving cascaded update operation.  In another thread, alter 
table add foreign key constraint is happening.  Under these 
circumstances, it is possible for the dml thread to access a 
dict_foreign_t object that has been freed by the ddl thread.  
The debug sync test case provides the sequence of operations.  
Without fix, the test case will crash the server (because of 
newly added assert).  With fix, the alter table stmt will return 
an error message.  
      
rb:947
approved by Jimmy Yang
2012-02-27 17:23:56 +05:30
Jimmy Yang
37d2bf8454 Fix Bug #64432 Port bug fix #54330 from mysql-5.1 to mysql-5.5 2012-02-24 21:21:07 +08:00
Georgi Kodinov
d4c35861e5 merge mysql-5.5->mysql-5.5-security 2012-02-18 10:58:31 +02:00
Georgi Kodinov
9f18fc5a06 merged mysql-5.5->mysql-5.5-security 2012-02-17 11:55:36 +02:00
Marko Mäkelä
4ea57c80b2 Merge mysql-5.1 to mysql-5.5. 2012-02-17 11:52:51 +02:00
Georgi Kodinov
387721101c merge mysql-5.1->mysql-5.1-security 2012-02-17 11:52:41 +02:00
Marko Mäkelä
6ff320e0f6 Merge mysql-5.1 to mysql-5.5. 2012-02-16 12:28:49 +02:00
Marko Mäkelä
4045c9976c Add instrumentation for Bug#13721257 RACE CONDITION IN UPDATES OR INSERTS
OF WIDE RECORDS

row_ins_index_entry_low(), row_upd_clust_rec(): Make a redo log
checkpoint if a DEBUG flag is set. Add DEBUG_SYNC around
btr_store_big_rec_extern_fields().

rb:946 approved by Jimmy Yang
2012-02-16 12:24:11 +02:00
Sunny Bains
ec47cb6034 Merge from mysql-5.1-innodb. 2012-02-10 13:04:10 +11:00
Georgi Kodinov
91c1c93019 merge mysql-5.5->mysql-5.5-security 2012-02-06 18:26:36 +02:00
Marko Mäkelä
567a422cf9 Merge mysql-5.1 to mysql-5.5. 2012-02-02 13:50:54 +02:00
Marko Mäkelä
39100cd984 Bug #13651627 Move ut_ad(0) from the beginning to the end of buf_page_print(),
print page dump

buf_page_print(): Remove the ut_ad(0) from the beginning. Add two flags
(enum buf_page_print_flags) that can be bitwise-ORed together:

BUF_PAGE_PRINT_NO_CRASH:
  Do not crash debug builds at the end of buf_page_print().
BUF_PAGE_PRINT_NO_FULL:
  Do not print the full page dump. This can be useful when adding
  diagnostic printout to flushing or to the doublewrite buffer.

trx_sys_doublewrite_init_or_restore_page(): Replace exit(1) with ut_error,
so that we can get a core dump if this extraordinary condition happens.

rb:924 approved by Sunny Bains
2012-02-02 12:31:57 +02:00