1. 13 Apr, 2015 2 commits
  2. 10 Apr, 2015 2 commits
  3. 09 Apr, 2015 2 commits
  4. 08 Apr, 2015 1 commit
  5. 07 Apr, 2015 2 commits
  6. 06 Apr, 2015 3 commits
    • Nisha's avatar
      Merge branch 'mysql-5.1' into mysql-5.5 · 9bacdef1
      Nisha authored
      9bacdef1
    • Nisha's avatar
      BUG#20754369: BACKPORT BUG#20007583 TO 5.1 · e65f3f6f
      Nisha authored
      Backporting the patch to 5.1 and 5.5
      e65f3f6f
    • aditya's avatar
      Bug #17299181 CREATE_TIME AND UPDATE_TIME ARE WRONG FOR PARTITIONED TABLES · 232d8bbd
      aditya authored
      PROBLEM
      
      Create time is calculated as last status change time of .frm file.
      The first problem was that innodb was passing file name as
      "table_name#po#p0.frm" to the stat() call which calculates the create time.
      Since there is no frm file with this name create_time will be stored as NULL.
      The second problem is ha_partition::info() updates stats for create time
      when HA_STATUS_CONST flag was set ,where as innodb calculates this statistic
      when HA_STATUS_TIME is set,which causes create_time to be set as NULL.
      
      Fix
      Pass proper .frm name to stat() call and calculate create time when
      HA_STATUS_CONST flag is set.
      232d8bbd
  7. 30 Mar, 2015 2 commits
  8. 26 Mar, 2015 2 commits
    • Sreeharsha Ramanavarapu's avatar
      2b345e7a
    • Sreeharsha Ramanavarapu's avatar
      Bug #20730155: BACKPORT BUG#19699237 TO 5.1 · c788e693
      Sreeharsha Ramanavarapu authored
      Backport from mysql-5.5 to mysql-5.1
      
      Bug# 19699237: UNINITIALIZED VARIABLE IN
                     ITEM_FIELD::STR_RESULT LEADS TO INCORRECT
                     BEHAVIOR
      
      ISSUE:
      ------
      When the following conditions are satisfied in a query, a
      server crash occurs:
      a) Two rows are compared using a NULL-safe equal-to operator.
      b) Each of these rows belong to different charsets.
      
      SOLUTION:
      ---------
      When one charset is converted to another for comparision,
      the constructor of "Item_func_conv_charset" is called.
      This will attempt to use the Item_cache if the string is a
      constant. This check succeeds because the "used_table_map"
      of the Item_cache class is never set to the correct value.
      Since it is mistakenly assumed to be a constant, it tries
      to fetch the relevant null value related fields which are
      yet to be initialized. This results in valgrind issues
      and wrong results.
      
      The fix is to update the "used_table_map" of "Item_cache".
      This will allow "Item_func_conv_charset" to realise that
      this is not a constant.
      c788e693
  9. 25 Mar, 2015 2 commits
  10. 24 Mar, 2015 2 commits
  11. 23 Mar, 2015 5 commits
    • Chaithra Gopalareddy's avatar
      26e845c1
    • Chaithra Gopalareddy's avatar
      Bug #20730220 : BACKPORT BUG#19880368 TO 5.1 · 044060fe
      Chaithra Gopalareddy authored
      Backport from mysql-5.5 to mysql-5.1
      
      Bug#19880368 : GROUP_CONCAT CRASHES AFTER DUMP_LEAF_KEY
      
      Problem:
      find_order_by_list does not update the address of order_item
      correctly after resolving.
      
      Solution:
      Change the ref_by address for a order_by field if its
      SUM_FUNC_ITEM to the address of the field present in
      all_fields.
      044060fe
    • Chaithra Gopalareddy's avatar
      7a361a27
    • Chaithra Gopalareddy's avatar
      Bug #20730129: BACKPORT BUG#19612819 TO 5.1 · a2cd622f
      Chaithra Gopalareddy authored
      Backport from mysql-5.5 to mysql-5.1
      
      Bug #19612819 :  FILESORT: ASSERTION FAILED: POS->FIELD != 0 || POS->ITEM != 0
      
      Problem:
      While getting the temp table field for a REF_ITEM
      make_sortorder is using the real_item. As a result
      server fails later with an assert.
      
      Solution:
      Do not use real_item to get the temp table field.
      Instead use the REF_ITEM itself as temp table fields
      are created for REF_ITEM not the real_item.
      a2cd622f
    • Sreeharsha Ramanavarapu's avatar
      Bug# 19573096: LOADING CORRUPTED GEOMETRY DATA INTO A · b7bdea94
      Sreeharsha Ramanavarapu authored
                     MYISAM TABLE CAUSES THE SERVER TO CRASH
      
      Issue:
      -----
      During index maintanence, R-tree node might need a split.
      In some cases the square of mbr could be calculated to
      infinite (as in this case) or to NaN. This is currently
      not handled. This is specific to MyISAM.
      
      SOLUTION:
      ---------
      If the calculated value in "mbr_join_square" is infinite or
      NaN, set it to max double value.
      
      Initialization of output parameters of "pick_seeds" is
      required if calculation is infinite (or negative infinite).
      
      Similar to the fix made for INNODB as part of Bug#19533996.
      b7bdea94
  12. 19 Mar, 2015 2 commits
    • Jon Olav Hauglid's avatar
      Merge branch 'mysql-5.1' into mysql-5.5 · 120907c0
      Jon Olav Hauglid authored
      Conflicts:
      	mysql-test/suite/sys_vars/r/transaction_alloc_block_size_basic.result
      	mysql-test/suite/sys_vars/r/transaction_prealloc_size_basic.result
      	mysql-test/suite/sys_vars/t/transaction_alloc_block_size_basic.test
      	mysql-test/suite/sys_vars/t/transaction_prealloc_size_basic.test
      	sql/mysqld.cc
      120907c0
    • Jon Olav Hauglid's avatar
      Bug#20730053: BACKPORT BUG#19770858 TO 5.1 · c7581bb5
      Jon Olav Hauglid authored
      Backport from mysql-5.5 to mysql-5.1 of:
      
      Bug19770858: MYSQLD CAN BE DRIVEN TO OOM WITH TWO SIMPLE SESSION VARS
      
      The problem was that the maximum value of the transaction_prealloc_size
      session system variable was ULONG_MAX which meant that it was possible
      to cause the server to allocate excessive amounts of memory.
      
      This patch fixes the problem by reducing the maxmimum value of
      transaction_prealloc_size and transaction_alloc_block_size down
      to 128K.
      
      Note that transactions will still be able to allocate more than
      128K if needed, this patch just reduces the amount that can be
      preallocated - as well as the maximum size of the incremental
      allocation blocks.
      
      (cherry picked from commit 540c9f7ebb428bbf9ec028feabe1f7f919fdefd9)
      
      Conflicts:
      	mysql-test/suite/sys_vars/r/transaction_alloc_block_size_basic.result
      	mysql-test/suite/sys_vars/r/transaction_alloc_block_size_basic_64.result
      	mysql-test/suite/sys_vars/t/disabled.def
      	mysql-test/suite/sys_vars/t/transaction_alloc_block_size_basic.test
      	sql/sys_vars.cc
      c7581bb5
  13. 13 Mar, 2015 2 commits
    • Venkatesh Duggirala's avatar
      Bug #20439913 CREATE TABLE DB.TABLE LIKE TMPTABLE IS · 59142d9a
      Venkatesh Duggirala authored
      BINLOGGED INCORRECTLY - BREAKS A SLAVE
      
      Submitted a incomplete patch with my previous push,
      re submitting the extra changes the required to make
      the patch complete.
      59142d9a
    • Venkatesh Duggirala's avatar
      Bug #20439913 CREATE TABLE DB.TABLE LIKE TMPTABLE IS BINLOGGED INCORRECTLY - BREAKS A SLAVE · 151b8ec4
      Venkatesh Duggirala authored
      Analysis:
      In row based replication, Master does not send temp table information
      to Slave. If there are any DDLs that involves in regular table that needs
      to be sent to Slave and a temp tables (which will not be available at Slave),
      the Master rewrites the query replacing temp table with it's defintion.
      Eg: create table regular_table like temptable.
      In rewrite logic, server is ignoring the database of regular table
      which can cause problems mentioned in this bug.
      
      Fix: dont ignore database information (if available) while
      rewriting the query
      151b8ec4
  14. 11 Mar, 2015 3 commits
    • Sreeharsha Ramanavarapu's avatar
      Revert "Bug #19573096: LOADING CORRUPTED GEOMETRY DATA INTO A" · 96974ea7
      Sreeharsha Ramanavarapu authored
      This reverts commit c7de768ec20f5167cff2c69a255d95ca2eded46a.
      96974ea7
    • Thirunarayanan Balathandayuthapani's avatar
      Bug #20417397 MYSQL SHOW ENGINE INNODB STATUS SHOWING NEGATIVE · 48869fce
      Thirunarayanan Balathandayuthapani authored
      			RESERVATION AND SIGNAL COUNT
      
      Problem:
      	Reservation and Signal count value shows negative value for show engine
      innodb statement.
      
      Solution:
      	This is happening due to counter overflow error. Reservation and Signal
      count values are defined as unsigned long but these variables are converted to
      long while printing it. Change Reservation and Signal count values as unsigned
      long datatype while printing it.
      Reviewed-by: default avatarMarko Mäkelä <marko.makela@oracle.com>
      Approved in bug page.
      48869fce
    • Sreeharsha Ramanavarapu's avatar
      Bug #19573096: LOADING CORRUPTED GEOMETRY DATA INTO A · 54d23ece
      Sreeharsha Ramanavarapu authored
                     MYISAM TABLE CAUSES THE SERVER TO CRASH
      
      Issue:
      -----
      During index maintanence, R-tree node might need a split.
      In some cases the square of mbr could be calculated to
      infinite (as in this case) or to NaN. This is currently
      not handled. This is specific to MyISAM.
      
      SOLUTION:
      ---------
      If the calculated value in "mbr_join_square" is infinite or
      NaN, set it to max double value.
      
      Initialization of output parameters of "pick_seeds" is
      required if calculation is infinite (or negative infinite).
      
      Similar to the fix made for INNODB as part of Bug#19533996.
      54d23ece
  15. 03 Mar, 2015 1 commit
    • Annamalai Gurusami's avatar
      Bug #20442523 CRASH WHEN CREATE TABLE VIOLATES FOREIGN KEY CONSTRAINT · 98b18c59
      Annamalai Gurusami authored
      Problem:
      
      This is a coding mistake during error handling.  When the specified foreign
      key constraint is wrong because of data type mismatch, the resulting
      foreign key object will not have valid foreign->id (it will be NULL.)
      
      Solution:
      
      While removing the foreign key object from dictionary cache during error
      handling, ensure that foreign->id is not null before using it.
      
      rb#8204 approved by Sunny.
      98b18c59
  16. 01 Mar, 2015 2 commits
  17. 27 Feb, 2015 3 commits
  18. 26 Feb, 2015 1 commit
    • Chaithra Gopalareddy's avatar
      Bug #19814337 - SERVER CRASHES IN ITEM_FUNC_GROUP_CONCAT::FIX_FIELDS ON · 08763096
      Chaithra Gopalareddy authored
      		3RD EXECUTION OF PS
      
      Problem:
      When order by is by a column number for a group concat function
      which has an outer reference, server fails in case of prepared
      statements on the third execution
      
      Analysis:
      When a group concat function has order by, the fields in order by
      are not resolved until execution if the input is a column number.
      During execution they get resolved after the temp table gets created.
      As a result they will be pointing to temp table fields which are
      runtime created objects. This results in dangling pointers leading
      to server failure.
      
      Solution:
      Reset the pointers for the order by fields to point to the original
      arguments after execution as they are invalid.
      Done in Item_func_group_concat::cleanup.
      08763096
  19. 25 Feb, 2015 1 commit
    • Mithun C Y's avatar
      Bug #20049521: CRASH IN MERGE_BUFFERS FILESORT.C WHEN INNODB WITH ORDER BY. · 2e3c2cd3
      Mithun C Y authored
      ISSUE:
      ------
      There can be up to MERGEBUFF2 number of sorted merge chunks,
      We need enough buffer space for at least one record from
      each merge chunks. If estimates are wrong(very low) and we
      allocate buffer space for less than MERGEBUFF2, then we will
      have issue in merge_buffers, if actual number of rows to be
      sorted is bigger than estimate and external filesort is
      chosen.
      
      SOLUTION:
      ---------
      Set number of rows to sort to be at least MERGEBUFF2.
      2e3c2cd3