1. 11 Jun, 2012 1 commit
    • Joerg Bruehe's avatar
      More changes to supporting the build of RPMs for ULN · 3da15359
      Joerg Bruehe authored
      from the MySQL 5.5 source tree.
      
      Contrary to the comment, the spec file for these ULN RPMs
      was missing in the previous changeset (blame ".bzrignore").
      
      This change now brings said spec file, and it adds cmake
      handling for the new files.
      
      Still for internal tool tests only, not yet ready for publishing.
      3da15359
  2. 08 Jun, 2012 1 commit
    • Joerg Bruehe's avatar
      First version of supporting the build of RPMs for ULN · a61c7c38
      Joerg Bruehe authored
      from the MySQL 5.5 source tree.
      
      This change adds the spec file for these ULN RPMs as well as
      several patches and additional sources, to be used only in ULN RPMs.
      All these files are in a new directory "SPECIFIC-ULN/".
      
      This commit is for internal tool tests only, not yet ready for publishing.
      a61c7c38
  3. 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
  4. 05 Jun, 2012 3 commits
  5. 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
  6. 31 May, 2012 6 commits
  7. 30 May, 2012 6 commits
  8. 29 May, 2012 3 commits
  9. 28 May, 2012 1 commit
    • Praveenkumar Hulakund's avatar
      Bug#14003080:65104: MAX_USER_CONNECTIONS WITH PROCESSLIST EMPTY · ca9a3a89
      Praveenkumar Hulakund authored
      Analysis:
      -------------
      If server is started with limit of MAX_CONNECTIONS and 
      MAX_USER_CONNECTIONS then only MAX_USER_CONNECTIONS of any particular
      users can be connected to server and total MAX_CONNECTIONS of client can
      be connected to server.
      
      Server maintains a counter for total CONNECTIONS and total CONNECTIONS 
      from particular user.
      
      Here, MAX_CONNECTIONS of connections are created to server. Out of this
      MAX_CONNECTIONS, connections from particular user (say USER1) are
      also created. The connections from USER1 is lesser than 
      MAX_USER_CONNECTIONS. After that there was one more connection request from
      USER1. Since USER1 can still create connections as he havent reached
      MAX_USER_CONNECTIONS, server increments counter of CONNECTIONS per user.
      As server already has MAX_CONNECTIONS of connections, next check to total
      CONNECTION count fails. In this case control is returned WITHOUT 
      decrementing the CONNECTIONS per user. So the counter per user CONNECTIONS goes
      on incrementing for each attempt until current connections are closed. 
      And because of this counter per CONNECTIONS reached MAX_USER_CONNECTIONS. 
      So, next connections form USER1 user always returns with MAX_USER_CONNECTION 
      limit error, even when total connection to sever are less than MAX_CONNECTIONS.
      
      Fix:
      -------------
      This issue is occurred because of not handling counters properly in the
      server. Changed the code to handle per user connection counters properly.
      ca9a3a89
  10. 25 May, 2012 2 commits
  11. 24 May, 2012 4 commits
    • Mayank Prasad's avatar
      Bug#13417440 : 63340: ARCHIVE FILE IO NOT INSTRUMENTED · c678b1a9
      Mayank Prasad authored
            
      Details:
       - Archive storage engine file access were not instrumented and thus
         were not shown in PS tables.
            
      Fix:
       - Added instrumentation code by using PS Apis for I/O.
      c678b1a9
    • Inaam Rana's avatar
      merge from 5.1 · e183e149
      Inaam Rana authored
      e183e149
    • Inaam Rana's avatar
      Bug #14100254 65389: MVCC IS BROKEN WITH IMPLICIT LOCK · 0bb636b3
      Inaam Rana authored
      rb://1088
      approved by: Marko Makela
      
      This bug was introduced in early stages of plugin. We were not
      checking for an implicit lock on sec index rec for trx_id that is
      stamped on current version of the clust_index in case where the
      clust_index has a previous delete marked version.
      0bb636b3
    • Sujatha Sivakumar's avatar
      Bug#13833962:DISABLE [NOTE] START BINLOG_DUMP TO SLAVE_SERVER(0) MESSAGES · e264eb87
      Sujatha Sivakumar authored
      IN THE ERROR LOG
            
      Problem:
      Using mysqlbinlog with the --read-from-remote-server option as shown below
      prints a message in error log for each call. This happens for 5.5 and above
      versions
            
      mysqlbinlog -uroot -p --read-from-remote-server --host=localhost test
            
      Message in error log file is given below:
      120312 10:27:57 [Note] Start binlog_dump to slave_server(0), pos(test, 4)
            
      The problem is that it can fill up the error log if the command is called
      very often.
            
      Analysis:
      The below mentioned print function is called from "mysql_binlog_send" function
      which causes the "Start binlog_dump..." string to be printed in error log file.
      
      sql_print_information("Start binlog_dump to master_thread_id(%lu) 
      slave_server(%d)..."
            
      Fix:
      A condition has been added in such a way that the 'sql_print_information' 
      will be invoked only when the "log_warnings" variable is set to >1 
      otherwise don't call the 'sql_print_information' function.
      e264eb87
  12. 23 May, 2012 3 commits
  13. 21 May, 2012 3 commits
    • Annamalai Gurusami's avatar
      Merge from mysql-5.1 to mysql-5.5 · 0b6a2e75
      Annamalai Gurusami authored
      0b6a2e75
    • Annamalai Gurusami's avatar
      Bug #12752572 61579: REPLICATION FAILURE WHILE · 3fcd55f6
      Annamalai Gurusami authored
      INNODB_AUTOINC_LOCK_MODE=1 AND USING TRIGGER
      
      When an insert stmt like "insert into t values (1),(2),(3)" is
      executed, the autoincrement values assigned to these three rows are
      expected to be contiguous.  In the given lock mode
      (innodb_autoinc_lock_mode=1), the auto inc lock will be released
      before the end of the statement.  So to make the autoincrement
      contiguous for a given statement, we need to reserve the auto inc
      values at the beginning of the statement.  
      
      Modified the fix based on review comment by Svoj.  
      3fcd55f6
    • Tor Didriksen's avatar
      Bug#13986705 CRASH IN GET_INTERVAL_VALUE() WITH DATE CALCULATION WITH UTF32 INTERVALS · b0a2b7c1
      Tor Didriksen authored
      This is a followup to the fix for Bug#12340997
      get_interval_value() was trying to parse the input string,
      looking for leading '-' while skipping whitespace.
      The macro my_isspace() does not work for utf32 character set,
      since my_charset_utf32_general_ci.ctype == NULL.
      
      Solution: convert input to ASCII before parsing,
      and use the character set of the returned ASCII string.
      b0a2b7c1
  14. 18 May, 2012 1 commit
    • Rohit Kalhans's avatar
      BUG#14005409 - 64624 · c64b88d6
      Rohit Kalhans authored
            
      Problem: After the fix for Bug#12589870, a new field that
      stores the length of db name was added in the buffer that
      stores the query to be executed. Unlike for the plain user
      session, the replication execution did not allocate the
      necessary chunk in Query-event constructor. This caused an
      invalid read while accessing this field.
            
      Solution: We fix this problem by allocating a necessary chunk
      in the buffer created in the Query_log_event::Query_log_event()
      and store the length of database name.
      c64b88d6
  15. 17 May, 2012 1 commit
    • Gopal Shankar's avatar
      Bug#12636001 : deadlock from thd_security_context · 047fea06
      Gopal Shankar authored
      PROBLEM:
      Threads end-up in deadlock due to locks acquired as described
      below,
      
      con1: Run Query on a table. 
        It is important that this SELECT must back-off while
        trying to open the t1 and enter into wait_for_condition().
        The SELECT then is blocked trying to lock mysys_var->mutex
        which is held by con3. The very significant fact here is
        that mysys_var->current_mutex will still point to LOCK_open,
        even if LOCK_open is no longer held by con1 at this point.
      
      con2: Try dropping table used in con1 or query some table.
        It will hold LOCK_open and be blocked trying to lock
        kernel_mutex held by con4.
      
      con3: Try killing the query run by con1.
        It will hold THD::LOCK_thd_data belonging to con1 while
        trying to lock mysys_var->current_mutex belonging to con1.
        But current_mutex will point to LOCK_open which is held
        by con2.
      
      con4: Get innodb engine status
        It will hold kernel_mutex, trying to lock THD::LOCK_thd_data
        belonging to con1 which is held by con3.
      
      So while technically only con2, con3 and con4 participate in the
      deadlock, con1's mysys_var->current_mutex pointing to LOCK_open
      is a vital component of the deadlock.
      
      CYCLE = (THD::LOCK_thd_data -> LOCK_open ->
               kernel_mutex -> THD::LOCK_thd_data)
      
      FIX:
      LOCK_thd_data has responsibility of protecting,
      1) thd->query, thd->query_length
      2) VIO
      3) thd->mysys_var (used by KILL statement and shutdown)
      4) THD during thread delete.
      
      Among above responsibilities, 1), 2)and (3,4) seems to be three
      independent group of responsibility. If there is different LOCK
      owning responsibility of (3,4), the above mentioned deadlock cycle
      can be avoid. This fix introduces LOCK_thd_kill to handle
      responsibility (3,4), which eliminates the deadlock issue.
      
      Note: The problem is not found in 5.5. Introduction MDL subsystem 
      caused metadata locking responsibility to be moved from TDC/TC to
      MDL subsystem. Due to this, responsibility of LOCK_open is reduced. 
      As the use of LOCK_open is removed in open_table() and 
      mysql_rm_table() the above mentioned CYCLE does not form.
      Revision ID for changes,
      open_table() = dlenev@mysql.com-20100727133458-m3ua9oslnx8fbbvz
      mysql_rm_table() = jon.hauglid@oracle.com-20101116100012-kxep9txz2fxy3nmw
      047fea06