1. 03 Jul, 2012 3 commits
    • Rohit Kalhans's avatar
      upmerge from mysql-5.1 to mysql-5.5 · 623f930a
      Rohit Kalhans authored
      623f930a
    • Rohit Kalhans's avatar
      BUG#11762667:MYSQLBINLOG IGNORES ERRORS WHILE WRITING OUTPUT · 176d6b1d
      Rohit Kalhans authored
      This is a followup patch for the bug enabling the test
      i_binlog.binlog_mysqlbinlog_file_write.test
      this was disabled in mysql trunk and mysql 5.5 as in the release
      build mysqlbinlog was not debug compiled whereas the mysqld was.
      Since have_debug.inc script checks only for mysqld to be debug
      compiled, the test was not being skipped on release builds.
      
      We resolve this problem by creating a new inc file 
      mysqlbinlog_have_debug.inc which checks exclusively for mysqlbinlog
      to be debug compiled. if not it skips the test.
       
      176d6b1d
    • Mayank Prasad's avatar
      Bug#13417440 : 63340: ARCHIVE FILE IO NOT INSTRUMENTED · 9f4f0699
      Mayank Prasad authored
      Details:
       - Modified test case to make sure its run for all and not only
         for archive Storage Engine.
      9f4f0699
  2. 29 Jun, 2012 8 commits
  3. 28 Jun, 2012 5 commits
    • Georgi Kodinov's avatar
      Bug #13708485: malformed resultset packet crashes client · 428ff7f8
      Georgi Kodinov authored
      Several fixes :
      
      * sql-common/client.c
      Added a validity check of the fields metadata packet sent 
      by the server.
      Now libmysql will check if the length of the data sent by
      the server matches what's expected by the protocol before
      using the data.
      
      * client/mysqltest.cc
      Fixed the error handling code in mysqltest to avoid sending
      new commands when the reading the result set failed (and 
      there are unread data in the pipe).
      
      * sql_common.h + libmysql/libmysql.c + sql-common/client.c
      unpack_fields() now generates a proper error when it fails.
      Added a new argument to this function to support the error 
      generation.
      
      * sql/protocol.cc
      Added a debug trigger to cause the server to send a NULL
      insted of the packet expected by the client for testing 
      purposes.
      428ff7f8
    • Evgeny Potemkin's avatar
      Bug#14248833: UPDATE ON INNODB TABLE ENTERS RECURSION · 0f7888f7
      Evgeny Potemkin authored
      Introduction of cost based decision on filesort vs index for UPDATE
      statements changed detection of the fact that the index used to scan the
      table is being updated. The new design missed the case of index merge
      when there is no single index to check. That was worked until a recent
      change in InnoDB after which it went into infinite recursion if update of
      the used index wasn't properly detected.
      
      The fix consists of 'used key being updated' detection code from 5.1.
      0f7888f7
    • Norvald H. Ryeng's avatar
      Null merge 5.1->5.5. · b128b1d4
      Norvald H. Ryeng authored
      b128b1d4
    • Norvald H. Ryeng's avatar
      Merge. · 537f7706
      Norvald H. Ryeng authored
      537f7706
    • Norvald H. Ryeng's avatar
      Merge · 52626ab1
      Norvald H. Ryeng authored
      52626ab1
  4. 19 Jun, 2012 2 commits
  5. 18 Jun, 2012 2 commits
    • Norvald H. Ryeng's avatar
      Merge 5.1->5.5. · 0d510988
      Norvald H. Ryeng authored
      0d510988
    • Norvald H. Ryeng's avatar
      Bug#13003736 CRASH IN ITEM_REF::WALK WITH SUBQUERIES · 5f61cc43
      Norvald H. Ryeng authored
      Problem: Some queries with subqueries and a HAVING clause that
      consists only of a column not in the select or grouping lists causes
      the server to crash.
      
      During parsing, an Item_ref is constructed for the HAVING column. The
      name of the column is resolved when JOIN::prepare calls fix_fields()
      on its having clause. Since the column is not mentioned in the select
      or grouping lists, a ref pointer is not found and a new Item_field is
      created instead. The Item_ref is replaced by the Item_field in the
      tree of HAVING clauses. Since the tree consists only of this item, the
      pointer that is updated is JOIN::having. However,
      st_select_lex::having still points to the Item_ref as the root of the
      tree of HAVING clauses.
      
      The bug is triggered when doing filesort for create_sort_index(). When
      find_all_keys() calls select->cond->walk() it eventually reaches
      Item_subselect::walk() where it continues to walk the having clauses
      from lex->having. This means that it finds the Item_ref instead of the
      new Item_field, and Item_ref::walk() tries to dereference the ref
      pointer, which is still null.
      
      The crash is reproducible only in 5.5, but the problem lies latent in
      5.1 and trunk as well.
      
      Fix: After calling fix_fields on the having clause in JOIN::prepare(),
      set select_lex::having to point to the same item as JOIN::having.
      
      This patch also fixes a bug in 5.1 and 5.5 that is triggered if the
      query is executed as a prepared statement. The Item_field is created
      in the runtime arena when the query is prepared, and the pointer to
      the item is saved by st_select_lex::fix_prepare_information() and
      brought back as a dangling pointer when the query is executed, after
      the runtime arena has been reclaimed.
      
      Fix: Backport fix from trunk that switches to the permanent arena
      before calling Item_ref::fix_fields() in JOIN::prepare().
      5f61cc43
  6. 15 Jun, 2012 2 commits
  7. 14 Jun, 2012 2 commits
  8. 13 Jun, 2012 3 commits
  9. 12 Jun, 2012 3 commits
    • Jon Olav Hauglid's avatar
      Bug#13586591 RQG GRAMMAR CONF/ENGINES/ENGINE_STRESS.YY · 6aab1cec
      Jon Olav Hauglid authored
                   CRASHES INNODB | TRX_STATE_NOT_STARTED
      
      The problem was that if DELETE with subselect caused a
      deadlock inside InnoDB, this deadlock was not properly
      handled by the SQL layer. This meant that the SQL layer
      would try to unlock the row after InnoDB had rolled
      back the transaction. This caused an assertion inside
      InnoDB.
      
      This patch fixes the problem by checking for errors
      reported by SQL_SELECT::skip_record() and not calling
      unlock_row() if any errors have been reported.
      6aab1cec
    • Manish Kumar's avatar
      BUG#12400221 - 60926: BINARY LOG EVENTS LARGER THAN MAX_ALLOWED_PACKET · 46ca66b9
      Manish Kumar authored
      Upmerge from mysql-5.1 -> mysql-5.5
      46ca66b9
    • Manish Kumar's avatar
      BUG#12400221 - 60926: BINARY LOG EVENTS LARGER THAN MAX_ALLOWED_PACKET · 1211b5d5
      Manish Kumar authored
      Problem
      ========
                  
      Replication breaks in the cases if the event length exceeds 
      the size of master Dump thread's max_allowed_packet.
                    
      The reason why this failure is occuring is because the event length is
      more than the total size of the max_allowed_packet, on addition of the  
      max_event_header length exceeds the max_allowed_packet of the DUMP thread.
      This causes the Dump thread to break replication and throw an error.
                            
      That can happen e.g with row-based replication in Update_rows event.
                  
      Fix
      ====
                
      The problem is fixed in 2 steps:
      
      1.) The Dump thread limit to read event is increased to the upper limit
          i.e. Dump thread reads whatever gets logged in the binary log.
      
      2.) On the slave side we increase the the max_allowed_packet for the
          slave's threads (IO/SQL) by increasing it to 1GB.
      
          This is done using the new server option (slave_max_allowed_packet)
          included, is used to regulate the max_allowed_packet of the  
          slave thread (IO/SQL) by the DBA, and facilitates the sending of
          large packets from the master to the slave.
      
          This causes the large packets to be received by the slave and apply
          it successfully.
      1211b5d5
  10. 08 Jun, 2012 1 commit
  11. 07 Jun, 2012 1 commit
    • Narayanan Venkateswaran's avatar
      WL#6161 Integrating with InnoDB codebase in MySQL 5.5 · f29bfa7e
      Narayanan Venkateswaran authored
            
      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.
      f29bfa7e
  12. 05 Jun, 2012 3 commits
  13. 01 Jun, 2012 4 commits
    • Annamalai Gurusami's avatar
      1bf83fa8
    • Annamalai Gurusami's avatar
      Bug #13933132: [ERROR] GOT ERROR -1 WHEN READING TABLE APPEARED · 08f36070
      Annamalai Gurusami authored
      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
      08f36070
    • Jon Olav Hauglid's avatar
      Bug#13982017: ALTER TABLE RENAME ENDS UP WITH ERROR 1050 (42S01) · 040a1fdd
      Jon Olav Hauglid authored
      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.
      040a1fdd
    • Annamalai Gurusami's avatar
      Merge from mysql-5.1 to mysql-5.5. · 633fcac1
      Annamalai Gurusami authored
      633fcac1
  14. 31 May, 2012 1 commit