Commit graph

4989 commits

Author SHA1 Message Date
Ashish Agarwal
d15e2f7214 BUG#13555854: CHECK AND REPAIR TABLE SHOULD BE MORE ROBUST [1]
ISSUE: Incorrect key file. Key file is corrupted,
       Reading incorrect key information (keyseg)
       from index file. Key definition in .MYI
       and .FRM file differs. Starting pointer
       to read the keyseg information is changed
       to a value greater than the pack_reclength.
       Memcpy tries to read keyseg information from
       unallocated memory which causes the crash.

SOLUTION: One more check added to compare the
          the key definition in .MYI and .FRM
          file. If the definition differ, server
          produces an error.
2012-07-23 14:05:13 +05:30
Jon Olav Hauglid
a47e778a61 Bug#12623923 Server can crash after failure to create
primary key with innodb tables

The bug was triggered if a single ALTER TABLE statement both
added and dropped indexes and ALTER TABLE failed during drop
(e.g. because the index was needed in a foreign key constraint).
In such cases, the server index information would get out of
sync with InnoDB - the added index would be present inside
InnoDB, but not in the server. This could then lead to InnoDB
error messages and/or server crashes.

The root cause is that new indexes are added before old indexes
are dropped. This means that if ALTER TABLE fails while dropping
indexes, index changes will be reverted in the server but not
inside InnoDB.

This patch fixes the problem by dropping any added indexes
if drop fails (for ALTER TABLE statements that both adds
and drops indexes). 

However, this won't work if we added a primary key as this
key might not be possible to drop inside InnoDB. Therefore,
we resort to the copy algorithm if a primary key is added
by an ALTER TABLE statement that also drops an index.

In 5.6 this bug is more properly fixed by the handler interface
changes done in the scope of WL#5534 "Online ALTER".
2012-07-10 16:13:02 +02:00
Ashish Agarwal
5f313125d4 BUG#13555854: CHECK AND REPAIR TABLE SHOULD BE MORE ROBUST [1]
ISSUE: Incorrect key file. Key file is corrupted,
       Reading incorrect key information (keyseg)
       from index file. Key definition in .MYI
       and .FRM file differs. Starting pointer
       to read the keyseg information is changed
       to a value greater than the pack_reclength.
       Memcpy tries to read keyseg information from
       unallocated memory which causes the crash.

SOLUTION: One more check added to compare the
          the key definition in .MYI and .FRM
          file. If the definition differ, server
          produces an error.
2012-07-02 15:20:23 +05:30
Jon Olav Hauglid
66ef5b0d48 Bug#14238406 NEW COMPILATION WARNINGS WITH GCC 4.7 (-WERROR=NARROWING)
Manual merge from mysql-5.1 to mysql-5.5
2012-06-29 13:36:01 +02:00
Jon Olav Hauglid
1ede2dd814 Bug#14238406 NEW COMPILATION WARNINGS WITH GCC 4.7 (-WERROR=NARROWING)
This patch fixes various compilation warnings of the type
"error: narrowing conversion of 'x' from 'datatype1' to
'datatype2'
2012-06-29 13:25:57 +02:00
Yasufumi Kinoshita
6058319dba Bug#14251529 : FIX FOR BUG 13704145 CREATES POSSIBLE RACE CONDITION
make buf_read_page_low() to treat DB_TABLESPACE_DELETED error correctly
rb#1129 approved by Inaam
2012-06-29 12:04:44 +09:00
Narayanan Venkateswaran
164080e4a8 WL#6161 Integrating with InnoDB codebase in MySQL 5.5
Changes in the InnoDB codebase required to compile and
integrate the MEB codebase with MySQL 5.5.

@ storage/innobase/btr/btr0btr.c
  Excluded buffer pool usage from MEB build.
 
  buf_pool_from_bpage calls are in buf0buf.ic, and
  the buffer pool functions from that file are
  disabled in MEB.
@ storage/innobase/buf/buf0buf.c
  Disabling more buffer pool functions unused in MEB.
@ storage/innobase/dict/dict0dict.c
  Disabling dict_ind_free that is unused in MEB.
@ storage/innobase/dict/dict0mem.c
  The include

  #include "ha_prototypes.h"

  Was causing conflicts with definitions in my_global.h

  Linking C executable mysqlbackup
  libinnodb.a(dict0mem.c.o): In function `dict_mem_foreign_table_name_lookup_set':
  dict0mem.c:(.text+0x91c): undefined reference to `innobase_get_lower_case_table_names'
  libinnodb.a(dict0mem.c.o): In function `dict_mem_referenced_table_name_lookup_set':
  dict0mem.c:(.text+0x9fc): undefined reference to `innobase_get_lower_case_table_names'
  libinnodb.a(dict0mem.c.o): In function `dict_mem_foreign_table_name_lookup_set':
  dict0mem.c:(.text+0x96e): undefined reference to `innobase_casedn_str'
  libinnodb.a(dict0mem.c.o): In function `dict_mem_referenced_table_name_lookup_set':
  dict0mem.c:(.text+0xa4e): undefined reference to `innobase_casedn_str'
  collect2: ld returned 1 exit status
  make[2]: *** [mysqlbackup] Error 1

  innobase_get_lower_case_table_names
  innobase_casedn_str
  are functions that are part of ha_innodb.cc that is not part of the build
        
  dict_mem_foreign_table_name_lookup_set
  function is not there in the current codebase, meaning we do not use it in MEB.
@ storage/innobase/fil/fil0fil.c
  The srv_fast_shutdown variable is declared in
  srv0srv.c that is not compiled in the
  mysqlbackup codebase.

  This throws an undeclared error.

  From the Manual
  ---------------

  innodb_fast_shutdown
  --------------------

  The InnoDB shutdown mode. The default value is 1
  as of MySQL 3.23.50, which causes a “fast� shutdown
  (the normal type of shutdown). If the value is 0,
  InnoDB does a full purge and an insert buffer merge
  before a shutdown. These operations can take minutes,
  or even hours in extreme cases. If the value is 1,
  InnoDB skips these operations at shutdown.

  This ideally does not matter from mysqlbackup
  @ storage/innobase/ha/ha0ha.c
  In file included from /home/narayanan/mysql-server/mysql-5.5-meb-rel3.8-innodb-integration-1/storage/innobase/ha/ha0ha.c:34:0:
  /home/narayanan/mysql-server/mysql-5.5-meb-rel3.8-innodb-integration-1/storage/innobase/include/btr0sea.h:286:17: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘*’ token
  make[2]: *** [CMakeFiles/innodb.dir/home/narayanan/mysql-server/mysql-5.5-meb-rel3.8-innodb-integration-1/storage/innobase/ha/ha0ha.c.o] Error 1
  make[1]: *** [CMakeFiles/innodb.dir/all] Error 2
  make: *** [all] Error 2

  # include "sync0rw.h" is excluded from hotbackup compilation in dict0dict.h

  This causes extern rw_lock_t*	btr_search_latch_temp; to throw a failure because
  the definition of rw_lock_t is not found.
@ storage/innobase/include/buf0buf.h
  Excluding buffer pool functions that are unused from the
  MEB codebase.
@ storage/innobase/include/buf0buf.ic
  replicated the exclusion of

  #include "buf0flu.h"
  #include "buf0lru.h"
  #include "buf0rea.h"

  by looking at the current codebase in <meb-trunk>/src/innodb
  @ storage/innobase/include/dict0dict.h
  dict_table_x_lock_indexes, dict_table_x_unlock_indexes, dict_table_is_corrupted,
  dict_index_is_corrupted, buf_block_buf_fix_inc_func are unused in MEB and was
  leading to compilation errors and hence excluded.
@ storage/innobase/include/dict0dict.ic
  dict_table_x_lock_indexes, dict_table_x_unlock_indexes, dict_table_is_corrupted,
  dict_index_is_corrupted, buf_block_buf_fix_inc_func are unused in MEB and was
  leading to compilation errors and hence excluded.
@ storage/innobase/include/log0log.h
  /home/narayanan/mysql-server/mysql-5.5-meb-rel3.8-innodb-integration-1/storage/innobase/include/log0log.h: At top level:
  /home/narayanan/mysql-server/mysql-5.5-meb-rel3.8-innodb-integration-1/storage/innobase/include/log0log.h:767:2: error: expected specifier-qualifier-list before Ã¢â  ‚¬Ëœmutex_t’

  mutex_t definitions were excluded as seen from ambient code
  hence excluding definition for log_flush_order_mutex also.
@ storage/innobase/include/os0file.h
  Bug in InnoDB code, create_mode should have been create.
@ storage/innobase/include/srv0srv.h
  In file included from /home/narayanan/mysql-server/mysql-5.5-meb-rel3.8-innodb-integration-1/storage/innobase/buf/buf0buf.c:50:0:
  /home/narayanan/mysql-server/mysql-5.5-meb-rel3.8-innodb-integration-1/storage/innobase/include/srv0srv.h: At top level:
  /home/narayanan/mysql-server/mysql-5.5-meb-rel3.8-innodb-integration-1/storage/innobase/include/srv0srv.h:120:16: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘srv_use_native_aio’

  srv_use_native_aio - we do not use native aio of the OS anyway from MEB. MEB does not compile
  InnoDB with this option. Hence disabling it.
@ storage/innobase/include/trx0sys.h
  [ 56%] Building C object CMakeFiles/innodb.dir/home/narayanan/mysql-server/mysql-5.5-meb-rel3.8-innodb-integration-1/storage/innobase/trx/trx0sys.c.o
  /home/narayanan/mysql-server/mysql-5.5-meb-rel3.8-innodb-integration-1/storage/innobase/trx/trx0sys.c: In function ‘trx_sys_read_file_format_id’:
  /home/narayanan/mysql-server/mysql-5.5-meb-rel3.8-innodb-integration-1/storage/innobase/trx/trx0sys.c:1499:20: error: ‘TRX_SYS_FILE_FORMAT_TAG_MAGIC_N’   undeclared (first use in this function)
  /home/narayanan/mysql-server/mysql-5.5-meb-rel3.8-innodb-integration-1/storage/innobase/trx/trx0sys.c:1499:20: note: each undeclared identifier is reported only once for  each function it appears in
  /home/narayanan/mysql-server/mysql-5.5-meb-rel3.8-innodb-integration-1/storage/innobase/trx/trx0sys.c: At top level:
  /home/narayanan/mysql-server/mysql-5.5-meb-rel3.8-innodb-integration-1/storage/innobase/include/buf0buf.h:607:1: warning: ‘buf_block_buf_fix_inc_func’ declared ‘static’ but never defined
  make[2]: *** [CMakeFiles/innodb.dir/home/narayanan/mysql-server/mysql-5.5-meb-rel3.8-innodb-integration-1/storage/innobase/trx/trx0sys.c.o] Error 1

  unused calls excluded to enable compilation
@ storage/innobase/mem/mem0dbg.c
    excluding #include "ha_prototypes.h" that lead to definitions in ha_innodb.cc
@ storage/innobase/os/os0file.c
    InnoDB not compiled with aio support from MEB anyway. Hence excluding this from
    the compilation.
@ storage/innobase/page/page0zip.c
  page0zip.c:(.text+0x4e9e): undefined reference to `buf_pool_from_block'
  collect2: ld returned 1 exit status

  buf_pool_from_block defined in buf0buf.ic, most of the file is excluded for compilation of MEB
@ storage/innobase/ut/ut0dbg.c
  excluding #include "ha_prototypes.h" since it leads to definitions in ha_innodb.cc
  innobase_basename(file) is defined in ha_innodb.cc. Hence excluding that also.
@ storage/innobase/ut/ut0ut.c
  cal_tm unused from MEB, was leading to earnings, hence disabling for MEB.
2012-06-07 19:14:26 +05:30
Annamalai Gurusami
a28a2ca798 Bug #13933132: [ERROR] GOT ERROR -1 WHEN READING TABLE APPEARED
WHEN KILLING

Suppose there is a query waiting for a lock.  If the user kills
this query, then "Got error -1 when reading table" error message
must not be logged in the server log file.  Since this is a user
requested interruption, no spurious error message must be logged
in the server log.  This patch will remove the error message from
the log.

approved by joh and tatjana
2012-06-01 14:12:57 +05:30
Jon Olav Hauglid
1c0388a5be Bug#13982017: ALTER TABLE RENAME ENDS UP WITH ERROR 1050 (42S01)
Fixed by backport of:
    ------------------------------------------------------------
    revno: 3402.50.156
    committer: Jon Olav Hauglid <jon.hauglid@oracle.com>
    branch nick: mysql-trunk-test
    timestamp: Wed 2012-02-08 14:10:23 +0100
    message:
      Bug#13417754 ASSERT IN ROW_DROP_DATABASE_FOR_MYSQL DURING DROP SCHEMA
      
      This assert could be triggered if an InnoDB table was being moved
      to a different database using ALTER TABLE ... RENAME, while this
      database concurrently was being dropped by DROP DATABASE.
      
      The reason for the problem was that no metadata lock was taken
      on the target database by ALTER TABLE ... RENAME.
      DROP DATABASE was therefore not blocked and could remove
      the database while ALTER TABLE ... RENAME was executing. This
      could cause the assert in InnoDB to be triggered.
      
      This patch fixes the problem by taking a IX metadata lock on
      the target database before ALTER TABLE ... RENAME starts
      moving a table to a different database.
      
      Note that this problem did not occur with RENAME TABLE which
      already takes the correct metadata locks.
      
      Also note that this patch slightly changes the behavior of
      ALTER TABLE ... RENAME. Before, the statement would abort and
      return an error if a lock on the target table name could not
      be taken immediately. With this patch, ALTER TABLE ... RENAME
      will instead block and wait until the lock can be taken 
      (or until we get a lock timeout). This also means that it is
      possible to get ER_LOCK_DEADLOCK errors in this situation
      since we allow ALTER TABLE ... RENAME to wait and not just
      abort immediately.
2012-06-01 09:31:24 +02:00
Annamalai Gurusami
4acca3431f Merge from mysql-5.1 to mysql-5.5. 2012-06-01 11:49:07 +05:30
Marc Alff
cf48fcfba3 Bug 14116252 - CANNOT BUILD ARCHIVE ENGINE WHEN WITH_PERFSCHEMA_STORAGE_ENGINE=0
Fixed a build break with compiling without the performance schema,
instrumentation should be protected by HAVE_PSI_INTERFACE
2012-05-31 11:47:13 +02:00
Annamalai Gurusami
a2bc9b3669 Bug #13933132: [ERROR] GOT ERROR -1 WHEN READING TABLE APPEARED
WHEN KILLING

Suppose there is a query waiting for a lock.  If the user kills
this query, then "Got error -1 when reading table" error message
must not be logged in the server log file.  Since this is a user
requested interruption, no spurious error message must be logged
in the server log.  This patch will remove the error message from
the log.

approved by joh and tatjana
2012-05-30 10:05:04 +05:30
Mayank Prasad
efe42792b3 Bug#13417440 : 63340: ARCHIVE FILE IO NOT INSTRUMENTED
Details:
 - Archive storage engine file access were not instrumented and thus
   were not shown in PS tables.
      
Fix:
 - Added instrumentation code by using PS Apis for I/O.
2012-05-24 23:00:32 +05:30
Inaam Rana
b91be27733 merge from 5.1 2012-05-24 12:44:27 -04:00
Inaam Rana
01748ce128 Bug #14100254 65389: MVCC IS BROKEN WITH IMPLICIT LOCK
rb://1088
approved by: Marko Makela

This bug was introduced in early stages of plugin. We were not
checking for an implicit lock on sec index rec for trx_id that is
stamped on current version of the clust_index in case where the
clust_index has a previous delete marked version.
2012-05-24 12:37:03 -04:00
Annamalai Gurusami
ce9e6b5a9a Bug #13943231: ALTER TABLE AFTER DISCARD MAY CRASH THE SERVER
The following scenario crashes our mysql server:

1.  set global innodb_file_per_table=1;
2.  create table t1(c1 int) engine=innodb;
3.  alter table t1 discard tablespace;
4.  alter table t1 add unique index(c1);

Step 4 crashes the server.  This patch introduces a check on discarded
tablespace to avoid the crash.

rb://1041 approved by Marko Makela
2012-05-16 16:36:49 +05:30
Venkata Sidagam
6b05e434bf Bug #13955256: KEYCACHE CRASHES, CORRUPTIONS/HANGS WITH,
FULLTEXT INDEX AND CONCURRENT DML.

Problem Statement:
------------------
1) Create a table with FT index.
2) Enable concurrent inserts.
3) In multiple threads do below operations repeatedly
   a) truncate table
   b) insert into table ....
   c) select ... match .. against .. non-boolean/boolean mode

After some time we could observe two different assert core dumps

Analysis:
--------
1)assert core dump at key_read_cache():
Two select threads operating in-parallel on same key 
root block.
1st select thread block->status is set to BLOCK_ERROR 
because the my_pread() in read_block() is returning '0'. 
Truncate table made the index file size as 1024 and pread 
was asked to get the block of count bytes(1024 bytes) 
from offset of 1024 which it cannot read since its 
"end of file" and retuning '0' setting 
"my_errno= HA_ERR_FILE_TOO_SHORT" and the key_file_length, 
key_root[0] is same i.e. 1024. Since block status has BLOCK_ERROR 
the 1st select thread enter into the free_block() and will 
be under wait on conditional mutex by making status as 
BLOCK_REASSIGNED and goes for wait_on_readers(). Other select 
thread will also work on the same block and sees the status as 
BLOCK_ERROR and enters into free_block(), checks for BLOCK_REASSIGNED 
and asserting the server.

2)assert core dump at key_write_cache():
One select thread and One insert thread.
Select thread gets the unlocks the 'keycache->cache_lock', 
which allows other threads to continue and gets the pread() 
return value as'0'(please see the explanation above) and 
tries to get the lock on 'keycache->cache_lock' and waits 
there for the lock.
Insert thread requests for the block, block will be assigned 
from the hash list and makes the page_status as 
'PAGE_WAIT_TO_BE_READ' and goes for the read_block(), waits 
in the queue since there are some other threads performing 
reads on the same block.
Select thread which was waiting for the 'keycache->cache_lock' 
mutex in the read_block() will continue after getting the my_pread() 
value as '0' and sets the block status as BLOCK_ERROR and goes to 
the free_block() and go to the wait_for_readers().
Now the insert thread will awake and continues. and checks 
block->status as not BLOCK_READ and it asserts.  

Fix:
---
In the full text code, multiple readers of index file is not guarded. 
Hence added below below code in _ft2_search() and walk_and_match().

to lock the key_root I have used below code in _ft2_search()
 if (info->s->concurrent_insert)
    mysql_rwlock_rdlock(&share->key_root_lock[0]);

and to unlock 
 if (info->s->concurrent_insert)
   mysql_rwlock_unlock(&share->key_root_lock[0]);

storage/myisam/ft_boolean_search.c:
  Since its a recursion function, to avoid confusion in taking and 
  releasing the locks, renamed _ft2_search() to _ft2_search_internal() 
  function. And _ft2_search() will take the lock, call 
  _ft2_search_internal() and release the lock in case of concurrent 
  inserts.
storage/myisam/ft_nlq_search.c:
  Added read locks code in walk_and_match()
2012-05-16 16:14:27 +05:30
Marko Mäkelä
5917c58a5d Bug#14025221 FOREIGN KEY REFERENCES FREED MEMORY AFTER DROP INDEX
dict_table_replace_index_in_foreign_list(): Replace the dropped index
also in the foreign key constraints of child tables that are
referencing this table.

row_ins_check_foreign_constraint(): If the underlying index is
missing, refuse the operation.

rb:1051 approved by Jimmy Yang
2012-05-15 15:04:39 +03:00
Annamalai Gurusami
31a6bcbee4 Merge from mysql-5.1 to mysql-5.5. 2012-05-16 16:33:22 +05:30
Venkata Sidagam
7244e84e6d Merging the fix from mysql-5.1 to mysql-5.5 2012-05-16 16:06:07 +05:30
Annamalai Gurusami
7a6c449c62 Bug #13943231: ALTER TABLE AFTER DISCARD MAY CRASH THE SERVER
The following scenario crashes our mysql server:

1.  set global innodb_file_per_table=1;
2.  create table t1(c1 int) engine=innodb;
3.  alter table t1 discard tablespace;
4.  alter table t1 add unique index(c1);

Step 4 crashes the server.  This patch introduces a check on discarded
tablespace to avoid the crash.

rb://1041 approved by Marko Makela
2012-05-16 15:23:56 +05:30
Venkata Sidagam
0e9c1e9fc3 Bug #13955256: KEYCACHE CRASHES, CORRUPTIONS/HANGS WITH,
FULLTEXT INDEX AND CONCURRENT DML.

Problem Statement:
------------------
1) Create a table with FT index.
2) Enable concurrent inserts.
3) In multiple threads do below operations repeatedly
   a) truncate table
   b) insert into table ....
   c) select ... match .. against .. non-boolean/boolean mode

After some time we could observe two different assert core dumps

Analysis:
--------
1)assert core dump at key_read_cache():
Two select threads operating in-parallel on same key 
root block.
1st select thread block->status is set to BLOCK_ERROR 
because the my_pread() in read_block() is returning '0'. 
Truncate table made the index file size as 1024 and pread 
was asked to get the block of count bytes(1024 bytes) 
from offset of 1024 which it cannot read since its 
"end of file" and retuning '0' setting 
"my_errno= HA_ERR_FILE_TOO_SHORT" and the key_file_length, 
key_root[0] is same i.e. 1024. Since block status has BLOCK_ERROR 
the 1st select thread enter into the free_block() and will 
be under wait on conditional mutex by making status as 
BLOCK_REASSIGNED and goes for wait_on_readers(). Other select 
thread will also work on the same block and sees the status as 
BLOCK_ERROR and enters into free_block(), checks for BLOCK_REASSIGNED 
and asserting the server.

2)assert core dump at key_write_cache():
One select thread and One insert thread.
Select thread gets the unlocks the 'keycache->cache_lock', 
which allows other threads to continue and gets the pread() 
return value as'0'(please see the explanation above) and 
tries to get the lock on 'keycache->cache_lock' and waits 
there for the lock.
Insert thread requests for the block, block will be assigned 
from the hash list and makes the page_status as 
'PAGE_WAIT_TO_BE_READ' and goes for the read_block(), waits 
in the queue since there are some other threads performing 
reads on the same block.
Select thread which was waiting for the 'keycache->cache_lock' 
mutex in the read_block() will continue after getting the my_pread() 
value as '0' and sets the block status as BLOCK_ERROR and goes to 
the free_block() and go to the wait_for_readers().
Now the insert thread will awake and continues. and checks 
block->status as not BLOCK_READ and it asserts.  

Fix:
---
In the full text code, multiple readers of index file is not guarded. 
Hence added below below code in _ft2_search() and walk_and_match().

to lock the key_root I have used below code in _ft2_search()
 if (info->s->concurrent_insert)
    mysql_rwlock_rdlock(&share->key_root_lock[0]);

and to unlock 
 if (info->s->concurrent_insert)
   mysql_rwlock_unlock(&share->key_root_lock[0]);

storage/myisam/ft_boolean_search.c:
  Since its a recursion function, to avoid confusion in taking and 
  releasing the locks, renamed _ft2_search() to _ft2_search_internal() 
  function. And _ft2_search() will take the lock, call 
  _ft2_search_internal() and release the lock in case of concurrent 
  inserts.
storage/myisam/ft_nlq_search.c:
  Added read locks code in walk_and_match()
2012-05-16 13:55:22 +05:30
Marko Mäkelä
a6da754a31 Merge mysql-5.1 to mysql-5.5. 2012-05-15 15:11:34 +03:00
Annamalai Gurusami
326b40c9c8 Merging from mysql-5.1 to mysql-5.5. 2012-05-10 10:33:16 +05:30
Annamalai Gurusami
391ea219c2 Bug #14007649 65111: INNODB SOMETIMES FAILS TO UPDATE ROWS INSERTED
BY A CONCURRENT TRANSACTIO

The member function QUICK_RANGE_SELECT::init_ror_merged_scan() performs
a table handler clone. Innodb does not provide a clone operation.  
The ha_innobase::clone() is not there. The handler::clone() does not 
take care of the ha_innobase->prebuilt->select_lock_type.  Because of 
this what happens is that for one index we do a locking read, and 
for the other index we were doing a non-locking (consistent) read. 
The patch introduces ha_innobase::clone() member function.  
It is implemented similar to ha_myisam::clone().  It calls the 
base class handler::clone() and then does any additional operation 
required.  I am setting the ha_innobase->prebuilt->select_lock_type 
correctly. 

rb://1060 approved by Marko
2012-05-10 10:18:31 +05:30
Sunanda Menon
074ce71e90 Merge from mysql-5.1.63-release 2012-05-08 07:19:14 +02:00
Joerg Bruehe
5be07ceadd Merge 5.5.24 back into main 5.5.
This is a weave merge, but without any conflicts.
In 14 source files, the copyright year needed to be updated to 2012.
2012-05-07 22:20:42 +02:00
Yasufumi Kinoshita
96b62513f6 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:40:12 +09: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
irana
02522904bc merge from 5.1 2012-04-26 08:21:25 -07:00
irana
1a2cf649dc InnoDB: Adjust error message when a dropped tablespace is accessed. 2012-04-26 08:17:14 -07:00
Inaam Rana
08ead005b1 Bug#13990648: 65061: LRU FLUSH RATE CALCULATION IS BASED ON INVALID VALUES
rb://1043
approved by: Sunny Bains

Two internal counters were incremented twice for a single
operations. The counters are:
srv_buf_pool_flushed
buf_lru_flush_page_count
2012-04-23 22:15:29 -04:00
Inaam Rana
2415d955c8 Bug#12677594 - 61575: INNODB: WARNING: IO_SETUP() FAILED WITH EAGAIN.
rb://1033
approved by: Marko Makela

Check return value from os_aio_init() and refuse to start if it fails.
2012-04-23 06:39:16 -04:00
Georgi Kodinov
a84ca72224 merge mysql-5.5->mysql-5.5-security 2012-04-12 14:04:12 +03:00
unknown
99b18a036c Bug#11815557 60269: MYSQL SHOULD REJECT ATTEMPTS TO CREATE SYSTEM
TABLES IN INCORRECT ENGINE

PROBLEM:
  CREATE/ALTER TABLE currently can move system tables like
mysql.db, user, host etc, to engines other than MyISAM. This is not
completely supported as of now, by mysqld. When some of system tables
like plugin, servers, event, func, *_priv, time_zone* are moved
to innodb, mysqld restart crashes. Currently system tables
can be moved to BLACKHOLE also!!!.

ANALYSIS:
  The problem is that there is no check before creating or moving
a system table to some particular engine.

  System tables are suppose to be residing in MyISAM. We can think
of restricting system tables to exist only in MyISAM. But, there could
be future needs of these system tables to be part of other engines
by design. For eg, NDB cluster expects some tables to be on innodb
or ndb engine. This calls for a solution, by which system
tables can be supported by any desired engine, with minimal effort.

FIX:
  The solution provides a handlerton interface using which,
mysqld server can query particular storage engine handlerton for
system tables that it supports. This way each storage engine
layer can define their own system database and system tables.

  The check_engine() function uses the new handlerton function
ha_check_if_supported_system_table() to check if db.tablename
provided in the DDL is supported by the SE.

Note: This fix has modified a test in help.test, which was moving
mysql.help_* to innodb. The primary intention of the test was not
to move them between engines.
2012-04-11 15:53:17 +05:30
Georgi Kodinov
7fa28bcf56 merge mysql-5.5->mysql-5.5-security 2012-04-10 14:23:17 +03:00
Georgi Kodinov
df905524b2 merge mysql-5.1->mysql-5.1-security 2012-04-10 14:21:57 +03:00
Sergey Glukhov
ea1b0492a0 5.1-security -> 5.5-security merge 2012-04-04 14:19:00 +04:00
Sergey Glukhov
b5c690aa54 Bug#11766300 59387: FAILING ASSERTION: CURSOR->POS_STATE == 1997660512 (BTR_PCUR_IS_POSITIONE
Bug#13639204 64111: CRASH ON SELECT SUBQUERY WITH NON UNIQUE INDEX
The crash happened due to wrong calculation
of key length during creation of reference for
sort order index. The problem is that
keyuse->used_tables can have OUTER_REF_TABLE_BIT enabled
but used_tables parameter(create_ref_for_key() func) does
not have it. So key parts which have OUTER_REF_TABLE_BIT
are ommited and it could lead to incorrect key length
calculation(zero key length).


mysql-test/r/subselect_innodb.result:
  test result
mysql-test/t/subselect_innodb.test:
  test case
sql/sql_select.cc:
  added OUTER_REF_TABLE_BIT to the used_tables parameter
  for create_ref_for_key() function.
storage/innobase/handler/ha_innodb.cc:
  added assertion, request from Inno team
storage/innodb_plugin/handler/ha_innodb.cc:
  added assertion, request from Inno team
2012-04-04 13:29:45 +04:00
Inaam Rana
96e9dd03ea Fix Sun Studio compiler warnings due to extra ',' introduced in
rev_id: inaam.rana@oracle.com-20120326134501-23554a8vhjg0wqbm
2012-04-03 09:45:10 -04:00
Sunny Bains
d1809a5c85 Bug #13817703 - auto_increment_offset != 1 + innodb_autoinc_lock_mode=1 => bulk inserts fail
Fix the calculation of the next autoinc value when offset > 1. Some of the
results have changed due to the changes in the allocation calculation. The
new calculation will result in slightly bigger gaps for bulk inserts.
  
rb://866 Approved by Jimmy Yang.
Backported from mysql-trunk (5.6)
2012-03-29 18:02:08 +11:00
Marc Alff
7553f9eefd Bug#13898343 THREAD LOOPS ENDLESSLY IN LF_PINBOX_PUT_PINS WHILE HOLDING
LOCK_THREAD_COUNT

When using the performance schema file io instrumentation in MySQL 5.5,
a thread would loop forever inside lf_pinbox_put_pins, when disconnecting.
It would also hold LOCK_thread_count while doing so, effectively killing the
server.

The root cause of the loop in lf_pinbox_put_pins() is a leak of LF_PINS,
when used with the filename_hash LF_HASH table in the performance schema.

This fix contains the following changes:

1)
Added the missing call to lf_hash_search_unpin(), to prevent the leak.

2)
In mysys/lf_alloc-pin.c, there was some extra debugging code
(MY_LF_EXTRA_DEBUG) written to detect precisely this kind of issues,
but it was never used.
Replaced MY_LF_EXTRA_DEBUG with DBUG_OFF, so that leaks similar to this one
can be always detected in regular debug builds.

3)
Backported the fix for the following bug, from 5.6 to 5.5:
Bug#13417446 - 63339: INCORRECT FILE PATH IN PEFORMANCE_SCHEMA ON WINDOWS
2012-03-28 17:54:30 +02:00
Gleb Shchepa
46d848b8e1 Bug #11880012: INDEX_SUBQUERY, BLACKHOLE,
HANG IN PREPARING WITH 100% CPU USAGE

Infinite loop in the subselect_indexsubquery_engine::exec()
function caused Server hang with 100% CPU usage.

The BLACKHOLE storage engine didn't update handler's
table->status variable after index operations, that
caused an infinite "while(!table->status)" execution.

Index access methods of the BLACKHOLE engine handler
have been updated to set table->status variable to
STATUS_NOT_FOUND or 0 when such a method returns a
HA_ERR_END_OF_FILE error or 0 respectively.


mysql-test/r/blackhole.result:
  Bug #11880012: INDEX_SUBQUERY, BLACKHOLE,
                 HANG IN PREPARING WITH 100% CPU USAGE
  
  New test file for the BLACKHOLE engine.
mysql-test/t/blackhole.test:
  Bug #11880012: INDEX_SUBQUERY, BLACKHOLE,
                 HANG IN PREPARING WITH 100% CPU USAGE
  
  New test file for the BLACKHOLE engine.
storage/blackhole/ha_blackhole.cc:
  Bug #11880012: INDEX_SUBQUERY, BLACKHOLE,
                 HANG IN PREPARING WITH 100% CPU USAGE
  
  Index access methods of the BLACKHOLE engine handler
  have been updated to set table->status variable to
  STATUS_NOT_FOUND or 0 when such a method returns a
  HA_ERR_END_OF_FILE error or 0 respectively, like
  we do in MyISAM storage engine.
2012-03-28 12:22:31 +04:00
Sunny Bains
1e10b60629 Merge from mysql-5.1. 2012-03-28 13:59:06 +11:00
Sunny Bains
83a5a20d81 Merge from mysql-5.0 2012-03-28 13:35:44 +11: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
Jimmy Yang
19d68d68df Fix Bug #13849910 - INNODB ASSERTS ON TOO LONG TABLENAME WHEN USING PARTITIONS
rb://981 approved by Sunny Bains
2012-03-22 11:22:54 +08:00
Georgi Kodinov
5bf1a28915 merge mysql-5.5->mysql-5.5-security 2012-03-21 14:56:29 +02:00
Georgi Kodinov
b9b6548966 merge mysql-5.1->mysql-5.1-security 2012-03-21 14:53:09 +02:00
Jimmy Yang
faa3ecdb07 backport Bug #47707 print some progress messages during shutdown of innodb
to mysql-5.5

rb://979 approved by Marko
2012-03-21 11:48:12 +08:00