1. 03 Sep, 2012 1 commit
  2. 31 Aug, 2012 2 commits
    • Annamalai Gurusami's avatar
      Bug #13453036 ERROR CODE 1118: ROW SIZE TOO LARGE - EVEN · f3a6816f
      Annamalai Gurusami authored
      THOUGH IT IS NOT.
      
      The following error message is misleading because it claims 
      that the BLOB space is not counted.  
      
      "ERROR 1118 (42000): Row size too large. The maximum row size for 
      the used table type, not counting BLOBs, is 8126. You have to 
      change some columns to TEXT or BLOBs"
      
      When the ROW_FORMAT=compact or ROW_FORMAT=REDUNDANT is used,
      the BLOB prefix is stored inline along with the row.  So 
      the above error message is changed as follows depending on
      the row format used:
      
      For ROW_FORMAT=COMPRESSED or ROW_FORMAT=DYNAMIC, the error
      message is as follows:
      
      "ERROR 42000: Row size too large (> 8126). Changing some
      columns to TEXT or BLOB may help. In current row format, 
      BLOB prefix of 0 bytes is stored inline."
      
      For ROW_FORMAT=COMPACT or ROW_FORMAT=REDUNDANT, the error
      message is as follows:
      
      "ERROR 42000: Row size too large (> 8126). Changing some
      columns to TEXT or BLOB or using ROW_FORMAT=DYNAMIC or 
      ROW_FORMAT=COMPRESSED may help. In current row
      format, BLOB prefix of 768 bytes is stored inline."
      
      rb://1252 approved by Marko Makela
      f3a6816f
    • unknown's avatar
      No commit message · 940d7cb3
      unknown authored
      No commit message
      940d7cb3
  3. 30 Aug, 2012 2 commits
    • Marko Mäkelä's avatar
      Bug#14554000 CRASH IN PAGE_REC_GET_NTH_CONST(NTH=0) DURING COMPRESSED · d37f6298
      Marko Mäkelä authored
      PAGE SPLIT
      
      page_rec_get_nth_const(): Map nth==0 to the page infimum.
      
      btr_compress(adjust=TRUE): Add a debug assertion for nth>0. The cursor
      should never be positioned on the page infimum.
      
      btr_index_page_validate(): Add test instrumentation for checking the
      return values of page_rec_get_nth_const() during CHECK TABLE, and for
      checking that the page directory slot 0 always contains only one
      record, the predefined page infimum record.
      
      page_cur_delete_rec(), page_delete_rec_list_end(): Add debug
      assertions guarding against accessing the page slot 0.
      
      page_copy_rec_list_start(): Clarify a comment about ret_pos==0.
      
      rb:1248 approved by Jimmy Yang
      d37f6298
    • Marko Mäkelä's avatar
      Bug#14547952: DEBUG BUILD FAILS ASSERTION IN RECORDS_IN_RANGE() · 961486e5
      Marko Mäkelä authored
      ha_innodb::records_in_range(): Remove a debug assertion
      that prohibits an open range (full table).
      
      The patch by Jorgen Loland only removed the assertion from the
      built-in InnoDB, not from the InnoDB Plugin.
      961486e5
  4. 28 Aug, 2012 1 commit
  5. 21 Aug, 2012 1 commit
    • Marko Mäkelä's avatar
      Fix regression from Bug#12845774 OPTIMISTIC INSERT/UPDATE USES WRONG · 3f249921
      Marko Mäkelä authored
      HEURISTICS FOR COMPRESSED PAGE SIZE
      
      The fix of Bug#12845774 was supposed to skip known-to-fail
      btr_cur_optimistic_insert() calls. There was only one such call, in
      btr_cur_pessimistic_update(). All other callers of
      btr_cur_pessimistic_insert() would release and reacquire the B-tree
      page latch before attempting the pessimistic insert. This would allow
      other threads to restructure the B-tree, allowing (and requiring) the
      insert to succeed as an optimistic (single-page) operation.
      
      Failure to attempt an optimistic insert before a pessimistic one would
      trigger an attempt to split an empty page.
      
      rb:1234 approved by Sunny Bains
      3f249921
  6. 20 Aug, 2012 2 commits
  7. 17 Aug, 2012 2 commits
  8. 16 Aug, 2012 3 commits
    • Marko Mäkelä's avatar
      Bug#12595091 POSSIBLY INVALID ASSERTION IN BTR_CUR_PESSIMISTIC_UPDATE() · e288e649
      Marko Mäkelä authored
      Facebook got a case where the page compresses really well so that
      btr_cur_optimistic_update() returns DB_UNDERFLOW, but when a record
      gets updated, the compression rate radically changes so that
      btr_cur_insert_if_possible() can not insert in place despite
      reorganizing/recompressing the page, leading to the assertion failing.
      
      rb:1220 approved by Sunny Bains
      e288e649
    • Marko Mäkelä's avatar
      Bug#12845774 OPTIMISTIC INSERT/UPDATE USES WRONG HEURISTICS FOR · 6d7f6baa
      Marko Mäkelä authored
      COMPRESSED PAGE SIZE
      
      This was submitted as MySQL Bug 61456 and a patch provided by
      Facebook. This patch follows the same idea, but instead of adding a
      parameter to btr_cur_pessimistic_insert(), we simply remove the
      btr_cur_optimistic_insert() call there and add it to the only caller
      that needs it.
      
      btr_cur_pessimistic_insert(): Do not try btr_cur_optimistic_insert().
      
      btr_insert_on_non_leaf_level_func(): Invoke btr_cur_optimistic_insert()
      before invoking btr_cur_pessimistic_insert().
      
      btr_cur_pessimistic_update(): Clarify in a comment why it is not
      necessary to invoke btr_cur_optimistic_insert().
      
      btr_root_raise_and_insert(): Assert that the root page is not empty.
      This could happen if a pessimistic insert (involving a split or merge)
      is performed without first attempting an optimistic (intra-page) insert.
      
      rb:1219 approved by Sunny Bains
      6d7f6baa
    • Marko Mäkelä's avatar
      Bug#13523839 ASSERTION FAILURES ON COMPRESSED INNODB TABLES · 95247de2
      Marko Mäkelä authored
      btr_cur_optimistic_insert(): Remove a bogus assertion. The insert may
      fail after reorganizing the page.
      
      btr_cur_optimistic_update(): Do not attempt to reorganize compressed pages,
      because compression may fail after reorganization.
      
      page_copy_rec_list_start(): Use page_rec_get_nth() to restore to the
      ret_pos, which may also be the page infimum.
      
      rb:1221
      95247de2
  9. 15 Aug, 2012 1 commit
    • Mattias Jonsson's avatar
      Bug#13025132 - PARTITIONS USE TOO MUCH MEMORY · bcee9f18
      Mattias Jonsson authored
      The buffer for the current read row from each partition
      (m_ordered_rec_buffer) used for sorted reads was
      allocated on open and freed when the ha_partition handler
      was closed or destroyed.
      
      For tables with many partitions and big records this could
      take up too much valuable memory.
      
      Solution is to only allocate the memory when it is needed
      and free it when nolonger needed. I.e. allocate it in
      index_init and free it in index_end (and to handle failures
      also free it on reset, close etc.)
      
      Also only allocating needed memory, according to
      partitioning pruning.
      
      Manually tested that it does not use as much memory and
      releases it after queries.
      bcee9f18
  10. 14 Aug, 2012 1 commit
    • Sujatha Sivakumar's avatar
      Bug#13596613:SHOW SLAVE STATUS GIVES WRONG OUTPUT WITH · 03bfc41b
      Sujatha Sivakumar authored
      MASTER-MASTER AND USING SET USE
      
      Problem:
      =======
      In a master-master set-up, a master can show a wrong
      'SHOW SLAVE STATUS' output.
      
      Requirements:
      - master-master
      - log_slave_updates
      
      This is caused when using SET user-variables and then using
      it to perform writes. From then on the master that performed
      the insert will have a SHOW SLAVE STATUS that is wrong and  
      it will never get updated until a write happens on the other
      master. On"Master A" the "exec_master_log_pos" is not
      getting updated.
      
      Analysis:
      ========
      Slave receives a "User_var" event from the master and after
      applying the event, when "log_slave_updates" option is
      enabled the slave tries to write this applied event into
      its own binary log. At the time of writing this event the
      slave should use the "originating server-id". But in the
      above case the sever always logs the  "user var events"
      by using its global server-id. Due to this in a
      "master-master" replication when the event comes back to the
      originating server the "User_var_event" doesn't get skipped.
      "User_var_events" are context based events and they always
      follow with a query event which marks their end of group.
      Due to the above mentioned problem with "User_var_event"
      logging the "User_var_event" never gets skipped where as
      its corresponding "query_event" gets skipped. Hence the
      "User_var" event always waits for the next "query event"
      and the "Exec_master_log_position" does not get updated
      properly.
      
      Fix:
      ===
      `MYSQL_BIN_LOG::write' function is used to write events
      into binary log. Within this function a new object for
      "User_var_log_event" is created and this new object is used
      to write the "User_var" event in the binlog. "User var"
      event is inherited from "Log_event". This "Log_event" has
      different overloaded constructors. When a "THD" object
      is present "Log_event(thd,...)" constructor should be used
      to initialise the objects and in the absence of a valid
      "THD" object "Log_event()" minimal constructor should be
      used. In the above mentioned problem always default minimal
      constructor was used which is incorrect. This minimal
      constructor is replaced with "Log_event(thd,...)".
      
      sql/log_event.h:
        Replaced the default constructor with another constructor
        which takes "THD" object as an argument.
      03bfc41b
  11. 11 Aug, 2012 1 commit
  12. 09 Aug, 2012 4 commits
  13. 08 Aug, 2012 1 commit
    • Rohit Kalhans's avatar
      BUG#11757312: MYSQLBINLOG DOES NOT ACCEPT INPUT FROM STDIN · ff04c5bd
      Rohit Kalhans authored
      WHEN STDIN IS A PIPE
                  
      Problem: Mysqlbinlog does not accept the input from STDIN when 
      STDIN is a pipe. This prevents the users from passing the input file
      through a shell pipe.    
      
      Background: The my_seek() function does not check if the file descriptor
      passed to it is regular (seekable) file. The check_header() function in
      mysqlbinlog calls the my_b_seek() unconditionally and it fails when
      the underlying file is a PIPE.  
                  
      Resolution: We resolve this problem by checking if the underlying file
      is a regular file by using my_fstat() before calling my_b_seek(). 
      If the underlying file is not seekable we skip the call to my_b_seek()
      in check_header().
      
      client/mysqlbinlog.cc:
        Added a check to avoid the my_b_seek() call if the
        underlying file is a PIPE.
      ff04c5bd
  14. 07 Aug, 2012 2 commits
    • Nirbhay Choubey's avatar
      Bug#13928675 MYSQL CLIENT COPYRIGHT NOTICE MUST · 5ad8292c
      Nirbhay Choubey authored
                   SHOW 2012 INSTEAD OF 2011
      
      * Added a new macro to hold the current year :
        COPYRIGHT_NOTICE_CURRENT_YEAR
      * Modified ORACLE_WELCOME_COPYRIGHT_NOTICE macro
        to take the initial year as parameter and pick
        current year from the above mentioned macro.
      5ad8292c
    • Harin Vadodaria's avatar
      Bug#14068244: INCOMPATIBILITY BETWEEN LIBMYSQLCLIENT/LIBMYSQLCLIENT_R · d86d0634
      Harin Vadodaria authored
                    AND LIBCRYPTO
      
      Problem: libmysqlclient_r exports symbols from yaSSL library which
               conflict with openSSL symbols. This issue is related to symbols
               used by CURL library and are defined in taocrypt. Taocrypt has
               dummy implementation of these functions. Due to this when a
               program which uses libcurl library functions is compiled using
               libmysqlclient_r and libcurl, it hits segmentation fault in
               execution phase.
      
      Solution: MySQL should not be exporting such symbols. However, these
                functions are not used by MySQL code at all. So avoid compiling
                them in the first place.
      d86d0634
  15. 05 Aug, 2012 1 commit
  16. 31 Jul, 2012 1 commit
  17. 27 Jul, 2012 2 commits
  18. 26 Jul, 2012 5 commits
    • Praveenkumar Hulakund's avatar
      BUG#13868860 - LIMIT '5' IS EXECUTED WITHOUT ERROR WHEN '5' · 44cd81da
      Praveenkumar Hulakund authored
                     IS PLACE HOLDER AND USE SERVER-SIDE 
      
      Analysis:
      LIMIT always takes nonnegative integer constant values. 
      
      http://dev.mysql.com/doc/refman/5.6/en/select.html
      
      So parsing of value '5' for LIMIT in SELECT fails.
      
      But, within prepared statement, LIMIT parameters can be
      specified using '?' markers. Value for the parameter can
      be supplied while executing the prepared statement.
      
      Passing string values, float or double value for LIMIT
      works well from CLI. Because, while setting the value
      for the parameters from the variable list (added using
      SET), if the value is for parameter LIMIT then its 
      converted to integer value. 
      
      But, when prepared statement is executed from the other
      interfaces as J connectors, or C applications etc.
      The value for the parameters are sent to the server
      with execute command. Each item in log has value and
      the data TYPE. So, While setting parameter value
      from this log, value is set to all the parameters
      with the same data type as passed.
      But here logic to convert value to integer type
      if its for LIMIT parameter is missing.
      Because of this,string '5' is set to LIMIT.
      And the same is logged into the binlog file too. 
      
      Fix:
      When executing prepared statement having parameter for
      CLI it worked fine, as the value set for the parameter
      is converted to integer. And this failed in other 
      interfaces as J connector,C Applications etc as this 
      conversion is missing.
      
      So, as a fix added check while setting value for the
      parameters. If the parameter is for LIMIT value then
      its converted to integer value.
      44cd81da
    • Venkata Sidagam's avatar
      Bug #12876932 - INCORRECT SELECT RESULT ON FEDERATED TABLE · b6ecca26
      Venkata Sidagam authored
      Fix for pb2 test failure.
      b6ecca26
    • Nirbhay Choubey's avatar
      Bug#13741677 MYSQL_SECURE_INSTALLATION DOES NOT · 55f3fd4d
      Nirbhay Choubey authored
                   WORK + SAVES ROOT PASSWORD TO DISK!
      
      The secure installation scripts connect to the
      server by storing the password in a temporary
      option file. Now, if the script gets killed or
      fails for some reason, the removal of the option
      file may not take place.
      
      This patch introduces following enhancements :
      * (.sh) Made sure that cleanup happens at every
        call to 'exit 1'. This is performed implicitly
        by END{} in pl.in.
      * (.pl.in) Added a warning in case unlink fails
        to delete the option/query files.
      * (.sh/.pl.in) Added more signals to the signal
        handler list. SIG# 1, 3, 6, 15
      55f3fd4d
    • Tor Didriksen's avatar
    • Venkata Sidagam's avatar
      Bug #12876932 - INCORRECT SELECT RESULT ON FEDERATED TABLE · aef1982b
      Venkata Sidagam authored
      Problem description:
      Table 't' created with two colums having compound index on both the 
      columns under innodb/myisam engine at remote machine. In the local 
      machine same table is created undet the federated engine.
      A select having where clause with along 'AND' operation gives wrong 
      results on local machine.
      
      Analysis: 
      The given query at federated engine is wrongly transformed by 
      federated::create_where_from_key() function and the same was sent to 
      the remote machine. Hence the local machine is showing wrong results.
      
      Given query "select c1 from t where c1 <= 2 and c2 = 1;"
      Query transformed, after ha_federated::create_where_from_key() function is:
      SELECT `c1`, `c2` FROM `t` WHERE  (`c1` IS NOT NULL ) AND 
      ( (`c1` >= 2)  AND  (`c2` <= 1) ) and the same sent to real_query().
      In the above the '<=' and '=' conditions were transformed to '>=' and 
      '<=' respectively.
      
      ha_federated::create_where_from_key() function behaving as below:
      The key_range is having both the start_key and end_key. The start_key 
      is used to get "(`c1` IS NOT NULL )" part of the where clause, this 
      transformation is correct. The end_key is used to get "( (`c1` >= 2) 
      AND  (`c2` <= 1) )", which is wrong, here the given conditions('<=' and '=') 
      are changed as wrong conditions('>=' and '<=').
      The end_key is having {key = 0x39fa6d0 "", length = 10, keypart_map = 3, 
      flag = HA_READ_AFTER_KEY}
      
      The store_length is having value '5'. Based on store_length and length 
      values the condition values is applied in HA_READ_AFTER_KEY switch case.
      The switch case 'HA_READ_AFTER_KEY' is applicable to only the last part of 
      the end_key and for previous parts it is going to 'HA_READ_KEY_OR_NEXT' case, 
      here the '>=' is getting added as a condition instead of '<='.
      
      Fix:
      Updated the 'if' condition in 'HA_READ_AFTER_KEY' case to affect for all 
      parts of the end_key. i.e 'i > 0' will used for end_key, Hence added it in 
      the if condition.
      
      
      mysql-test/suite/federated/federated.test:
        modified the federated.inc file location
      mysql-test/suite/federated/federated_archive.test:
        modified the federated.inc file location
      mysql-test/suite/federated/federated_bug_13118.test:
        modified the federated.inc file location
      mysql-test/suite/federated/federated_bug_25714.test:
        modified the federated.inc file location
      mysql-test/suite/federated/federated_bug_35333.test:
        modified the federated.inc file location
      mysql-test/suite/federated/federated_debug.test:
        modified the federated.inc file location
      mysql-test/suite/federated/federated_innodb.test:
        modified the federated.inc file location
      mysql-test/suite/federated/federated_server.test:
        modified the federated.inc file location
      mysql-test/suite/federated/federated_transactions.test:
        modified the federated.inc file location
      mysql-test/suite/federated/include/federated.inc:
        moved the file from federated suite to federated/include folder
      mysql-test/suite/federated/include/federated_cleanup.inc:
        moved the file from federated suite to federated/include folder
      mysql-test/suite/federated/include/have_federated_db.inc:
        moved the file from federated suite to federated/include folder
      storage/federated/ha_federated.cc:
        updated the 'if condition' in ha_federated::create_where_from_key() 
        function.
      aef1982b
  19. 25 Jul, 2012 1 commit
  20. 24 Jul, 2012 1 commit
  21. 19 Jul, 2012 3 commits
    • Bjorn Munch's avatar
      Reverting broken configure/make stuff · 0893a90f
      Bjorn Munch authored
      0893a90f
    • Bjorn Munch's avatar
      Bug #14035452 - MODULARIZE MYSQL_CLIENT_TEST · 6aaf1579
      Bjorn Munch authored
        Added new minimal client using same framework
        Added internal test using it
        Small changes to top level make/configure/cmake to have it built
      6aaf1579
    • Venkata Sidagam's avatar
      Bug #12615411 - server side help doesn't work as first statement · 913e3a84
      Venkata Sidagam authored
      Problem description:
      Giving "help 'contents'" in the mysql client as a first statement
      gives error
      
      Analysis:
      In com_server_help() function the "server_cmd" variable was
      initialised with buffer->ptr(). And the "server_cmd" variable is not
      updated since we are passing "'contents'"(with single quote) so the
      buffer->ptr() consists of the previous buffer values and it was sent
      to the mysql_real_query() hence we are getting error.
      
      Fix:
      We are not initialising the "server_cmd" variable and we are updating
      the variable with "server_cmd= cmd_buf" in any of the case i.e with
      single quote or without single quote for the contents.
      As part of error message improvement, added new error message in case
      of "help 'contents'".
      
      client/mysql.cc:
        com_server_help(): Properly updated the server_cmd variable and improved
        the error message.
      913e3a84
  22. 18 Jul, 2012 1 commit
    • Chaithra Gopalareddy's avatar
      Bug#11762052: 54599: BUG IN QUERY PLANNER ON QUERIES WITH · ddcd6867
      Chaithra Gopalareddy authored
                           "ORDER BY" AND "LIMIT BY" CLAUSE
      
      PROBLEM:
      When a 'limit' clause is specified in a query along with
      group by and order by, optimizer chooses wrong index
      there by examining more number of rows than required.
      However without the 'limit' clause, optimizer chooses
      the right index.
      
      ANALYSIS:
      With respect to the query specified, range optimizer chooses
      the first index as there is a range present ( on 'a'). Optimizer
      then checks for an index which would give records in sorted
      order for the 'group by' clause.
      
      While checking chooses the second index (on 'c,b,a') based on
      the 'limit' specified and the selectivity of
      'quick_condition_rows' (number of rows present in the range)
      in 'test_if_skip_sort_order' function. 
      But, it fails to consider that an order by clause on a
      different column will result in scanning the entire index and 
      hence the estimated number of rows calculated above are 
      wrong (which results in choosing the second index).
      
      FIX:
      Do not enforce the 'limit' clause in the call to
      'test_if_skip_sort_order' if we are creating a temporary
      table. Creation of temporary table indicates that there would be
      more post-processing and hence will need all the rows.
      
      This fix is backported from 5.6. This problem is fixed in 5.6 as   
      part of changes for work log #5558
      
      
      mysql-test/r/subselect.result:
        Changes for Bug#11762052 results in the correct number of rows.
      sql/sql_select.cc:
        Do not pass the actual 'limit' value if 'need_tmp' is true.
      ddcd6867
  23. 12 Jul, 2012 1 commit
    • Annamalai Gurusami's avatar
      Bug #11765218 58157: INNODB LOCKS AN UNMATCHED ROW EVEN THOUGH USING · 357a008a
      Annamalai Gurusami authored
      RBR AND RC
      
      Description: When scanning and locking rows with < or <=, InnoDB locks
      the next row even though row based binary logging and read committed
      is used.
      
      Solution: In the handler, when the row is identified to fall outside
      of the range (as specified in the query predicates), then request the
      storage engine to unlock the row (if possible). This is done in
      handler::read_range_first() and handler::read_range_next().
      357a008a