1. 02 Feb, 2012 7 commits
  2. 01 Feb, 2012 1 commit
  3. 31 Jan, 2012 11 commits
  4. 30 Jan, 2012 5 commits
  5. 27 Jan, 2012 1 commit
  6. 26 Jan, 2012 5 commits
    • Jorgen Loland's avatar
      BUG 13413535 followup: Fix gcc warning · 0b7831ac
      Jorgen Loland authored
      0b7831ac
    • Marko Mäkelä's avatar
      Bug #13413535 61104: INNODB: FAILING ASSERTION: PAGE_GET_N_RECS(PAGE) > 1 · 9dfc545a
      Marko Mäkelä authored
      This fix does not remove the underlying cause of the assertion
      failure. It just works around the problem, allowing a corrupted
      secondary index to be fixed by DROP INDEX and CREATE INDEX (or in the
      worst case, by re-creating the table).
      
      ibuf_delete(): If the record to be purged is the last one in the page
      or it is not delete-marked, refuse to purge it. Instead, write an
      error message to the error log and let a debug assertion fail.
      
      ibuf_set_del_mark(): If the record to be delete-marked is not found,
      display some more information in the error log and let a debug
      assertion fail.
      
      row_undo_mod_del_unmark_sec_and_undo_update(),
      row_upd_sec_index_entry(): Let a debug assertion fail when the record
      to be delete-marked is not found.
      
      buf_page_print(): Add ut_ad(0) so that corruption will be more
      prominent in stress testing with debug binaries. Add ut_ad(0) here and
      there where corruption is noticed.
      
      btr_corruption_report(): Display some data on page_is_comp() mismatch.
      
      btr_assert_not_corrupted(): A wrapper around btr_corruption_report().
      Assert that page_is_comp() agrees with the table flags.
      
      rb:911 approved by Inaam Rana
      9dfc545a
    • Guilhem Bichot's avatar
      merge from 5.1 · ce345853
      Guilhem Bichot authored
      ce345853
    • Guilhem Bichot's avatar
      Fixes for: · 440d871b
      Guilhem Bichot authored
      BUG#13519696 - 62940: SELECT RESULTS VARY WITH VERSION AND
      WITH/WITHOUT INDEX RANGE SCAN
      BUG#13453382 - REGRESSION SINCE 5.1.39, RANGE OPTIMIZER WRONG
      RESULTS WITH DECIMAL CONVERSION
      BUG#13463488 - 63437: CHAR & BETWEEN WITH INDEX RETURNS WRONG
      RESULT AFTER MYSQL 5.1.
      Those are all cases where the range optimizer got it wrong
      with > and >=.
      440d871b
    • Tor Didriksen's avatar
      5fa3887c
  7. 25 Jan, 2012 7 commits
    • Nuno Carvalho's avatar
      BUG#12403008 RPL_HEARTBEAT_BASIC FAILS SPORADICALLY ON PUSHBUILD · 279917ef
      Nuno Carvalho authored
      rpl_heartbeat_basic test fails sporadically on pushbuild because did
      not received all heartbeats from slave in circular replication.
      
      MASTER_HEARTBEAT_PERIOD had the default value (slave_net_timeout/2) so
      wait on "Heartbeat event received on master", that only waits for 1
      minute, sometimes timeout before heartbeat arrives. Fixed setting a
      smaller period value.
      279917ef
    • Tor Didriksen's avatar
      Bug#13359121 LARGE NUMBERS, /STRINGS/DTOA.C:662 · 56a2ff83
      Tor Didriksen authored
      Bug#12985021 SIMPLE QUERY WITH DECIMAL NUMBERS TAKE AN
      
      When parsing the fractional part of a string which
      is to be converted to double, we can stop after a few digits:
      the extra digits will not contribute to the actual result anyways.
      56a2ff83
    • Tor Didriksen's avatar
      6ebd4ffe
    • Tor Didriksen's avatar
      Bug#13463415 63502: INCORRECT RESULTS OF BIGINT AND DECIMAL COMPARISON · 07fd88d5
      Tor Didriksen authored
      Bug#11758543 50756: BIGINT '100' MATCHES 1.001E2
      
      Expressions of the form
            BIGINT_COL <compare> <non-integer constant>
      
            should be done either as decimal, or float.
      
            Currently however, such comparisons are done as int,
            which means that the constant may be truncated,
            and yield false positives/negatives for all queries
            where compare is '>' '<' '>=' '<=' '=' '!='.
      
            BIGINT_COL IN <list of contstants>
            and
            BIGINT_COL BETWEEN <constant> AND <constant>
            are also affected.
      07fd88d5
    • Dmitry Shulga's avatar
      Fixed bug#11753187 (formerly known as bug 44585): SP_CACHE BEHAVES AS · d460f168
      Dmitry Shulga authored
      MEMORY LEAK.
      
      Background:
       - There are caches for stored functions and stored procedures (SP-cache);
       - There is no similar cache for events;
       - Triggers are cached together with TABLE objects;
       - Those SP-caches are per-session (i.e. specific to each session);
       - A stored routine is represented by a sp_head-instance internally;
       - SP-cache basically contains sp_head-objects of stored routines, which
         have been executed in a session;
       - sp_head-object is added into the SP-cache before the corresponding
         stored routine is executed;
       - SP-cache is flushed in the end of the session.
      
      The problem was that SP-cache might grow without any limit. Although this
      was not a pure memory leak (the SP-cache is flushed when session is closed),
      this is still a problem, because the user might take much memory by
      executing many stored routines.
      
      The patch fixes this problem in the least-intrusive way. A soft limit
      (similar to the size of table definition cache) is introduced. To represent
      such limit the new runtime configuration parameter 'stored_program_cache'
      is introduced. The value of this parameter is stored in the new global
      variable stored_program_cache_size that used to control the size of SP-cache
      to overflow. 
      
      The parameter 'stored_program_cache' limits number of cached routines for
      each thread. It has the following min/default/max values given from support:
        min = 256, default = 256, max = 512 * 1024.
      Also it should be noted that this parameter limits the size of 
      each cache (for stored procedures and for stored functions) separately.
      
      The SP-cache size is checked after top-level statement is parsed.
      If SP-cache size exceeds the limit specified by parameter
      'stored_program_cache' then SP-cache is flushed and memory allocated for
      cache objects is freed. Such approach allows to flush cache safely 
      when there are dependencies among stored routines.
      d460f168
    • Marko Mäkelä's avatar
      Merge mysql-5.1 to mysql-5.5. · 7bec00e1
      Marko Mäkelä authored
      7bec00e1
    • Marko Mäkelä's avatar
      btr_cur_search_to_nth_level(): Add a debug assertion · 1f9c1f09
      Marko Mäkelä authored
      and some Valgrind instrumentation.
      1f9c1f09
  8. 24 Jan, 2012 3 commits
    • chuck.bell@oracle.com's avatar
      BUG#12969301 : mysql_plugin: enable is ignored if plugin exists · f3f59aed
      chuck.bell@oracle.com authored
      This patch changes the mechanism by which the client enables a 
      plugin. Instead of using INSERT IGNORE to reload a plugin library,
      it now uses REPLACE INTO. This allows users to load a library
      multiple times replacing the existing values in the mysql.plugin
      table. This allows users to replace the symbol reference to a
      different dl name in the table. Thus permitting enabling of 
      multiple versions of the same library without first disabling
      the old version.
      
      A regression test was added to ensure this feature works.
      f3f59aed
    • Alexander Barkov's avatar
      Merging from mysql-5.5 · fd5e40fa
      Alexander Barkov authored
      fd5e40fa
    • Alexander Barkov's avatar
      Merging from mysql-5.1 · 11279f98
      Alexander Barkov authored
      11279f98