1. 20 Aug, 2009 2 commits
    • Martin Hansson's avatar
      Bug#46616: Merge · 2a15307c
      Martin Hansson authored
      mysql-test/r/auto_increment.result:
        Bug#46616: Test result.
      mysql-test/t/auto_increment.test:
        Bug#46616: Test case.
      sql/sql_update.cc:
        Bug#46616: Fix.
      2a15307c
    • Martin Hansson's avatar
      Bug#46616: Assertion `!table->auto_increment_field_not_null' on · fa0f3de5
      Martin Hansson authored
      view manipulations
            
      The bespoke flag was not properly reset after last call to 
      fill_record. Fixed by resetting in caller mysql_update.
      
      mysql-test/r/auto_increment.result:
        Bug#46616: Test result.
      mysql-test/t/auto_increment.test:
        Bug#46616: Test case.
      sql/sql_update.cc:
        Bug#46616: Fix.
      fa0f3de5
  2. 14 Aug, 2009 1 commit
  3. 13 Aug, 2009 4 commits
    • Davi Arnaut's avatar
      Merge from mysql-5.0-bugteam. · 4ad24a83
      Davi Arnaut authored
      4ad24a83
    • Davi Arnaut's avatar
      Bug#46013: rpl_extraColmaster_myisam fails on pb2 · a825d8c0
      Davi Arnaut authored
      Bug#45243: crash on win in sql thread clear_tables_to_lock() -> free()
      Bug#45242: crash on win in mysql_close() -> free()
      Bug#45238: rpl_slave_skip, rpl_change_master failed (lost connection) for STOP SLAVE
      Bug#46030: rpl_truncate_3innodb causes server crash on windows
      Bug#46014: rpl_stm_reset_slave crashes the server sporadically in pb2
      
      When killing a user session on the server, it's necessary to
      interrupt (notify) the thread associated with the session that
      the connection is being killed so that the thread is woken up
      if waiting for I/O. On a few platforms (Mac, Windows and HP-UX)
      where the SIGNAL_WITH_VIO_CLOSE flag is defined, this interruption
      procedure is to asynchronously close the underlying socket of
      the connection.
      
      In order to enable this schema, each connection serving thread
      registers its VIO (I/O interface) so that other threads can
      access it and close the connection. But only the owner thread of
      the VIO might delete it as to guarantee that other threads won't
      see freed memory (the thread unregisters the VIO before deleting
      it). A side note: closing the socket introduces a harmless race
      that might cause a thread attempt to read from a closed socket,
      but this is deemed acceptable.
      
      The problem is that this infrastructure was meant to only be used
      by server threads, but the slave I/O thread was registering the
      VIO of a mysql handle (a client API structure that represents a
      connection to another server instance) as a active connection of
      the thread. But under some circumstances such as network failures,
      the client API might destroy the VIO associated with a handle at
      will, yet the VIO wouldn't be properly unregistered. This could
      lead to accesses to freed data if a thread attempted to kill a
      slave I/O thread whose connection was already broken.
      
      There was a attempt to work around this by checking whether
      the socket was being interrupted, but this hack didn't work as
      intended due to the aforementioned race -- attempting to read
      from the socket would yield a "bad file descriptor" error.
      
      The solution is to add a hook to the client API that is called
      from the client code before the VIO of a handle is deleted.
      This hook allows the slave I/O thread to detach the active vio
      so it does not point to freed memory.
      
      server-tools/instance-manager/mysql_connection.cc:
        Add stub method required for linking.
      sql-common/client.c:
        Invoke hook.
      sql/client_settings.h:
        Export hook.
      sql/slave.cc:
        Introduce hook that clears the active VIO before it is freed
        by the client API.
      a825d8c0
    • Ramil Kalimullin's avatar
      Fix for bug #46614: Assertion in show_create_trigger() · bf9e9f67
      Ramil Kalimullin authored
      on SHOW CREATE TRIGGER + MERGE table
      
      Problem: SHOW CREATE TRIGGER erroneously relies on fact
      that we have the only underlying table for a trigger
      (wrong for merge tables).
      
      Fix: remove erroneous assert().
      
      
      mysql-test/r/merge.result:
        Fix for bug #46614: Assertion in show_create_trigger() 
        on SHOW CREATE TRIGGER + MERGE table
          - test result.
      mysql-test/t/merge.test:
        Fix for bug #46614: Assertion in show_create_trigger() 
        on SHOW CREATE TRIGGER + MERGE table
          - test case.
      sql/sql_show.cc:
        Fix for bug #46614: Assertion in show_create_trigger() 
        on SHOW CREATE TRIGGER + MERGE table
          - unnecessary assert() removed as we may have more than 1 
        tables open e.g. for a merge table.
      bf9e9f67
    • unknown's avatar
      BUG#45574 CREATE IF NOT EXISTS is not binlogged if the object exists · decfa124
      unknown authored
      There is an inconsistency with DROP DATABASE|TABLE|EVENT IF EXISTS and
      CREATE DATABASE|TABLE|EVENT IF NOT EXISTS. DROP IF EXISTS statements are
      binlogged even if either the DB, TABLE or EVENT does not exist. In
      contrast, Only the CREATE EVENT IF NOT EXISTS is binlogged when the EVENT
      exists.  
      
      This patch fixes the following cases for all the replication formats:
      CREATE DATABASE IF NOT EXISTS.
      CREATE TABLE IF NOT EXISTS,
      CREATE TABLE IF NOT EXISTS ... LIKE,
      CREAET TABLE IF NOT EXISTS ... SELECT.
      
      sql/sql_insert.cc:
        Part of the code was moved from the create_table_from_items to select_create::prepare.
        When replication is row based, CREATE TABLE IF NOT EXISTS.. SELECT is binlogged if the table exists.
      decfa124
  4. 12 Aug, 2009 7 commits
    • Mattias Jonsson's avatar
      merge · 8ab2d814
      Mattias Jonsson authored
      8ab2d814
    • Konstantin Osipov's avatar
      A follow up patch for the follow up patch for Bug#45829 · c07c64a5
      Konstantin Osipov authored
      "CREATE TABLE TRANSACTIONAL PAGE_CHECKSUM ROW_FORMAT=PAGE accepted, 
      does nothing".
      
      Put back stubs for members of structures that are shared between
      sql/ and pluggable storage engines. to not break ABI unnecessarily.
      To be NULL-merged into 5.4, where we do break the ABI already.
      c07c64a5
    • Konstantin Osipov's avatar
      A follow up patch for Bug#45829 "CREATE TABLE TRANSACTIONAL · 333d2dd3
      Konstantin Osipov authored
      PAGE_CHECKSUM ROW_FORMAT=PAGE accepted, does nothing"
      Remove unused code that would lead to warnings when compiling
      sql_yacc.yy.
      
      
      sql/handler.h:
        Remove unused defines.
      sql/sql_yacc.yy:
        Remove unused grammar.
      sql/table.h:
        Remove unused TABLE members.
      333d2dd3
    • Mattias Jonsson's avatar
      manual merge · 2e76de9e
      Mattias Jonsson authored
      2e76de9e
    • Mattias Jonsson's avatar
      merge · bda10bab
      Mattias Jonsson authored
      bda10bab
    • unknown's avatar
      Manual Merge · 30a67026
      unknown authored
      30a67026
    • unknown's avatar
      BUG#45516 SQL thread does not use database charset properly · 6b1580c8
      unknown authored
              
      Replication SQL thread does not set database default charset to 
      thd->variables.collation_database properly, when executing LOAD DATA binlog.
      This bug can be repeated by using "LOAD DATA" command in STATEMENT mode.
              
      This patch adds code to find the default character set of the current database 
      then assign it to thd->db_charset when slave server begins to execute a relay log.
      The test of this bug is added into rpl_loaddata_charset.test 
      6b1580c8
  5. 11 Aug, 2009 5 commits
  6. 10 Aug, 2009 4 commits
  7. 08 Aug, 2009 1 commit
    • Davi Arnaut's avatar
      Bug#45010: invalid memory reads during parsing some strange statements · 357430de
      Davi Arnaut authored
      The problem is that the lexer could inadvertently skip over the
      end of a query being parsed if it encountered a malformed multibyte
      character. A specially crated query string could cause the lexer
      to jump up to six bytes past the end of the query buffer. Another
      problem was that the laxer could use unfiltered user input as
      a signed array index for the parser maps (having upper and lower
      bounds 0 and 256 respectively).
      
      The solution is to ensure that the lexer only skips over well-formed
      multibyte characters and that the index value of the parser maps
      is always a unsigned value.
      
      mysql-test/r/ctype_recoding.result:
        Update test case result: ending backtick is not skipped over anymore.
      sql/sql_lex.cc:
        Characters being analyzed must be unsigned as they can be
        used as indexes for the parser maps. Only skip over if the
        string is a valid multi-byte sequence.
      tests/mysql_client_test.c:
        Add test case for Bug#45010
      357430de
  8. 07 Aug, 2009 1 commit
    • Martin Hansson's avatar
      Bug#46454: MySQL wrong index optimisation leads to incorrect result & crashes · 1164f8a6
      Martin Hansson authored
      Problem 1:
      When the 'Using index' optimization is used, the optimizer may still - after
      cost-based optimization - decide to use another index in order to avoid using
      a temporary table. But when this happens, the flag to the storage engine to 
      read index only (not table) was still set. Fixed by resetting the flag in the 
      storage engine and TABLE structure in the above scenario, unless the new index
      allows for the same optimization.
      Problem 2:
      When a 'ref' access method was employed by cost-based optimizer, (when the column
      is non-NULLable), it was assumed that it needed no initialization if 'quick' access
      methods (since they are based on range scan). When ORDER BY optimization overrides 
      the decision, however, it expects to have this initialized and hence crashes. 
      Fixed in 5.1 (was fixed in 6.0 already) by initializing 'quick' even when there's 
      'ref' access. 
      
      mysql-test/r/order_by.result:
        Bug#46454: Test result.
      mysql-test/t/order_by.test:
        Bug#46454: Test case.
      sql/sql_select.cc:
        Bug#46454: 
        Problem 1 fixed in make_join_select()
        Problem 2 fixed in test_if_skip_sort_order()
      sql/table.h:
        Bug#46454: Added comment to field.
      1164f8a6
  9. 06 Aug, 2009 5 commits
    • Ignacio Galarza's avatar
      Auto-merge · 2c190aea
      Ignacio Galarza authored
      2c190aea
    • Ignacio Galarza's avatar
      046267cf
    • Mattias Jonsson's avatar
      Bug#46478: timestamp field incorrectly defaulted · 060590dc
      Mattias Jonsson authored
      when partition is reoganized.
      
      Problem was that table->timestamp_field_type was not changed
      before copying rows between partitions.
      
      fixed by setting it to TIMESTAMP_NO_AUTO_SET as the first thing
      in fast_alter_partition_table, so that all if-branches is covered.
      060590dc
    • Satya B's avatar
      Fix for BUG#45816 - assertion failure with index containing double · ee9aff79
      Satya B authored
                          column on partitioned table
            
            
      An assertion 'ASSERT_COULUMN_MARKED_FOR_READ' is failed if the query 
      is executed with index containing double column on partitioned table.
      The problem is that assertion expects all the fields which are read,
      to be in the read_set.
            
      In this query only the field 'a' is in the readset as the tables in
      the query are joined by the field 'a' and so the assertion fails 
      expecting other field 'b'.
            
      Since the function cmp() is just comparison of two parameters passed, 
      the assertion is not required.
            
      Fixed by removing the assertion in the double fields comparision
      function and also fixed the index initialization to do ordered
      index scan with RW LOCK which ensures all the fields from a key are in
      the read_set.
       
      
      Note: this bug is not reproducible with other datatypes because the
            assertion doesn't exist in comparision function for other 
            datatypes.
      
      mysql-test/r/partition.result:
        Testcase for BUG#45816
      mysql-test/t/partition.test:
        Testcase for BUG#45816
      sql/field.cc:
        Removed the assertion ASSERT_COLUMN_MARED_FOR_READ in Field_double::cmp()
        function
      sql/ha_partition.cc:
        Fixed index_int() method to make it initialize the read_set properly if
        ordered index scan with RW lock is requested.
      ee9aff79
    • unknown's avatar
      Bug #45630 rpl_trigger.test causes valgrind failures within nptl_pthread_exit_hack_handler · 13c44afe
      unknown authored
      The server shutdown and start code triggered the valgrind failures 
      within nptl_pthread_exit_hack_handler on Ubuntu 9.04, x86 (but not amd64) 
      in rpl_trigger.test file.
      
      For fixing the bug, suppress valgrind failures within nptl_pthread_exit_hack_handler 
      on Ubuntu 9.04, x86 (but not amd64). Because the server shutdown and start
      code has been heavily used in mysql test set.
      
      mysql-test/valgrind.supp:
        Add code for suppressing valgrind failures within nptl_pthread_exit_hack_handler on Ubuntu 9.04, x86 (but not amd64).
      13c44afe
  10. 05 Aug, 2009 1 commit
  11. 04 Aug, 2009 3 commits
  12. 03 Aug, 2009 2 commits
  13. 02 Aug, 2009 1 commit
    • Alfranio Correia's avatar
      BUG#43264 Test rpl_trigger is failing randomly w/ use of copy_file in 5.0 · f8d7a710
      Alfranio Correia authored
      The test case fails sporadically on Windows while trying to overwrite an unused
      binary log. The problem stems from the fact that MySQL on Windows does not
      immediately unlock/release a file while the process that opened and closed it is
      still running. In BUG 38603, this issue was circumvented by stopping the MySQL
      process, copying the file and then restarting the MySQL process. 
      
      Unfortunately, such facilities are not available in the 5.0.  Other approaches
      such as stopping the slave and issuing change master do not work because the relay
      log file and index are not closed when a slave is stopped. So to fix the problem,
      we simply don't run on windows the part of the test that was failing.
      f8d7a710
  14. 01 Aug, 2009 2 commits
  15. 31 Jul, 2009 1 commit