1. 10 Feb, 2012 4 commits
  2. 07 Feb, 2012 1 commit
  3. 06 Feb, 2012 4 commits
    • Georgi Kodinov's avatar
    • Georgi Kodinov's avatar
      merged mysql-5.1->mysql-5.1-security · 145043fd
      Georgi Kodinov authored
      145043fd
    • Georgi Kodinov's avatar
      merged mysql-5.0->mysql-5.0-security · 12376c17
      Georgi Kodinov authored
      12376c17
    • Vasil Dimov's avatar
      Fix Bug#11754376 45976: INNODB LOST FILES FOR TEMPORARY TABLES ON · 17afdb90
      Vasil Dimov authored
      GRACEFUL SHUTDOWN
      
      During startup mysql picks up .frm files from the tmpdir directory and
      tries to drop those tables in the storage engine.
      
      The problem is that when tmpdir ends in / then ha_innobase::delete_table()
      is passed a string like "/var/tmp//#sql123", then it wrongly normalizes it
      to "/#sql123" and calls row_drop_table_for_mysql() which of course fails
      to delete the table entry from the InnoDB dictionary cache.
      ha_innobase::delete_table() returns an error but nevertheless mysql wipes
      away the .frm file and the entry in the InnoDB dictionary cache remains
      orphaned with no easy way to remove it.
      
      The "no easy" way to remove it is to create a similar temporary table again,
      copy its .frm file to tmpdir under "#sql123.frm" and restart mysqld with
      tmpdir=/var/tmp (no trailing slash) - this way mysql will pick the .frm file
      after restart and will try to issue drop table for "/var/tmp/#sql123"
      (notice do double slash), ha_innobase::delete_table() will normalize it to
      "tmp/#sql123" and row_drop_table_for_mysql() will successfully remove the
      table entry from the dictionary cache.
      
      The solution is to fix normalize_table_name_low() to normalize things like
      "/var/tmp//table" correctly to "tmp/table".
      
      This patch also adds a test function which invokes
      normalize_table_name_low() with various inputs to make sure it works
      correctly and a mtr test that calls this test function.
      
      Reviewed by:	Marko (http://bur03.no.oracle.com/rb/r/929/)
      17afdb90
  4. 03 Feb, 2012 1 commit
    • Ashish Agarwal's avatar
      BUG#11748748 - 37280: CHECK AND REPAIR TABLE REPORT TABLE · 8862a5b5
      Ashish Agarwal authored
                            CORRUPTED WHEN RUN CONCURRENTLY WITH
      
      ISSUE: Table corruption due to concurrent queries.
             Different threads running check, repair query
             along with insert. Locks not properly acquired
             in repair query. Rows are inserted inbetween
             repair query.
      
      SOLUTION: Mutex lock is acquired before the
                repair call. Concurrent queries wont
                effect the call to repair.
      8862a5b5
  5. 02 Feb, 2012 4 commits
  6. 01 Feb, 2012 1 commit
  7. 31 Jan, 2012 4 commits
  8. 30 Jan, 2012 2 commits
    • Ramil Kalimullin's avatar
      Fix for BUG#13596377: MYSQL CRASHES ON STARTUP ON FREEBSD IN PB2 · f94cf3fb
      Ramil Kalimullin authored
      Fix for #36428/#38364 backported into 5.0.
      f94cf3fb
    • Gopal Shankar's avatar
      Bug#13105873 :Valgrind Warning: CRASH IN FOREIGN · 04c5e521
      Gopal Shankar authored
            KEY HANDLING ON SUBSEQUENT CREATE TABLE IF NOT EXISTS
            
            PROBLEM:
            --------
            Consider a SP routine which does CREATE TABLE
            with REFERENCES clause. The first call to this routine
            invokes parser and the parsed items are cached, so as 
            to avoid parsing for the second execution of the routine.
            
            It is obsevered that valgrind reports a warning
            upon read of thd->lex->alter_info->key_list->Foreign_key object,
            which seem to be pointing to a invalid memory address
            during second time execution of the routine. Accessing this object
            theoretically could cause a crash.
            
            ANALYSIS:
            ---------
            The problem stems from the fact that for some reason
            elements of ref_columns list in thd->lex->alter_info->
            key_list->Foreign_key object are changed to point to
            objects allocated on runtime memory root.
            
            During the first execution of routine we create
            a copy of thd->lex->alter_info object.
            As part of this process we create a clones of objects in
            Alter_info::key_list and of Foreign_key object in particular.
            Then Foreign_key object is cloned for some reason we
            perform shallow copies of both Foreign_key::ref_columns
            and Foreign_key::columns list. So new instance of 
            Foreign_key object starts to SHARE contents of ref_columns
            and columns list with the original instance.
            After that as part of cloning process we call
            list_copy_and_replace_each_value() for elements of
            ref_columns list. As result ref_columns lists in both
            original and cloned Foreign_key object start to contain
            pointers to Key_part_spec objects allocated on runtime
            memory root because of shallow copy.
            
            So when we start copying of thd->lex->alter_info object
            during the second execution of stored routine we indeed
            encounter pointer to the Key_part_spec object allocated
            on runtime mem-root which was cleared during at the end
            of previous execution. This is done in sp_head::execute(), 
            by a call to free_root(&execute_mem_root,MYF(0));
            As result we get valgrind warnings about accessing 
            unreferenced memory.
            
            FIX:
            ----
            The safest solution to this problem is to 
            fix Foreign_key(Foreign_key, MEM_ROOT) constructor to do
            a deep copy of columns lists, similar to Key(Key, MEM_ROOT) 
            constructor.
      04c5e521
  9. 27 Jan, 2012 1 commit
    • Tor Didriksen's avatar
      Bug#13580775 ASSERTION FAILED: RECORD_LENGTH == M_RECORD_LENGTH · 1422d0b0
      Tor Didriksen authored
      Bug#13011410 CRASH IN FILESORT CODE WITH GROUP BY/ROLLUP
      
      The assert in 13580775 is visible in 5.6 only, 
      but shows that all versions are vulnerable.
      13011410 crashes in all versions.
      
      filesort tries to re-use the sort buffer between invocations in order to save
      malloc/free overhead.
      The fix for Bug 11748783 - 37359: FILESORT CAN BE MORE EFFICIENT.
      added an assert that buffer properties (num_records, record_length) are
      consistent between invocations. Indeed, they are not necessarily consistent.
        
      Fix: re-allocate the sort buffer if properties change.
      1422d0b0
  10. 26 Jan, 2012 1 commit
    • 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
  11. 25 Jan, 2012 1 commit
  12. 24 Jan, 2012 2 commits
  13. 23 Jan, 2012 1 commit
    • Alexander Barkov's avatar
      Bug#11752408 - 43593: DUMP/BACKUP/RESTORE/UPGRADE TOOLS FAILS BECAUSE OF UTF8_GENERAL_CI · e56caa38
      Alexander Barkov authored
      Introducing new collations:
      utf8_general_mysql500_ci and ucs2_general_mysql500_ci,
      to reproduce behaviour of utf8_general_ci and ucs2_general_ci
      from mysql-5.1.23 (and earlier).
      
      The collations are added to simplify upgrade from mysql-5.1.23 and earlier.
      
      Note: The patch does not make new server start over old data automatically.
      Some manual upgrade procedures are assumed.
      
      Paul: please get in touch with me to discuss upgrade procedures
      when documenting this bug.
      
      modified:
        include/m_ctype.h
        mysql-test/r/ctype_utf8.result
        mysql-test/t/ctype_utf8.test
        mysys/charset-def.c
        strings/ctype-ucs2.c
        strings/ctype-utf8.c
      e56caa38
  14. 17 Jan, 2012 1 commit
  15. 16 Jan, 2012 4 commits
    • Marko Mäkelä's avatar
      Bug#13496818 ASSERTION: REC_PAGE_NO > 4 IN IBUF CONTRACTION · d985ac1f
      Marko Mäkelä authored
      Relax a bogus debug assertion.
      Approved by Jimmy Yang on IM.
      d985ac1f
    • Nuno Carvalho's avatar
      BUG#11893288 60542: RPL.RPL_EXTRA_COL_MASTER_* DOESN'T TEST WHAT WAS INTENDED · bffc7ec8
      Nuno Carvalho authored
      Test extra/rpl_tests/rpl_extra_col_master.test (used by
      rpl_extra_col_master_*) ends with the active connection pointing to the
      slave. Thus, the two last tests never succeed in changing the binlog
      format of the master away from 'row'. With correct active connection
      (master) tests fail for binlog 'statement' and 'mixed' formats.
      
      Tests rpl_extra_col_master_* only run when binary log format is
      row.  Statement and mix replication do not make sense in this
      tests since it will try to execute statements on columns that do
      not exist.  This fix is basically a backport from mysql-5.5, see
      changes done as part of BUG 39934.
      bffc7ec8
    • Marko Mäkelä's avatar
      buf_page_get_known_nowait(): Relax a bogus debug assertion. · 97e0eeb3
      Marko Mäkelä authored
      When mode==BUF_KEEP_OLD, buffered inserts are being merged to the page.
      It is possible that a read request for a page was pending while the page
      was freed in DROP INDEX or DROP TABLE. In these cases, it is OK (although
      useless) to merge the buffered changes to the freed page.
      97e0eeb3
    • Annamalai Gurusami's avatar
      Bug #11765438 58406: · fd6f9a1e
      Annamalai Gurusami authored
      ISSUES WITH COPYING PARTITIONED INNODB TABLES FROM LINUX TO WINDOWS
      
      This problem was already fixed in mysql-trunk as part of bug #11755924.  I am 
      backporting the fix to mysql-5.1.  
      fd6f9a1e
  16. 12 Jan, 2012 4 commits
  17. 11 Jan, 2012 3 commits
  18. 10 Jan, 2012 1 commit
    • Nirbhay Choubey's avatar
      BUG#11760384 - 52792: mysqldump in XML mode does not dump · 7faf69dd
      Nirbhay Choubey authored
                           routines.
      
      mysqldump in xml mode did not dump routines, events or
      triggers.
      
      This patch fixes this issue by fixing the if conditions
      that disallowed the dump of above mentioned objects in
      xml mode, and added the required code to enable dump
      in xml format.
      7faf69dd