1. 02 Sep, 2009 1 commit
  2. 31 Aug, 2009 3 commits
  3. 28 Aug, 2009 2 commits
  4. 27 Aug, 2009 2 commits
    • Alfranio Correia's avatar
      BUG#46861 Auto-closing of temporary tables broken by replicate-rewrite-db · fe03c7dc
      Alfranio Correia authored
      When a connection is dropped any remaining temporary table is also automatically
      dropped and the SQL statement of this operation is written to the binary log in
      order to drop such tables on the slave and keep the slave in sync. Specifically,
      the current code base creates the following type of statement:
      DROP /*!40005 TEMPORARY */ TABLE IF EXISTS `db`.`table`;
      
      Unfortunately, appending the database to the table name in this manner circumvents
      the replicate-rewrite-db option (and any options that check the current database).
      To solve the issue, we started writing the statement to the binary as follows:
      use `db`; DROP /*!40005 TEMPORARY */ TABLE IF EXISTS `table`;
      fe03c7dc
    • Georgi Kodinov's avatar
      Bug #46749: Segfault in add_key_fields() with outer subquery level · 8ca8f70d
      Georgi Kodinov authored
        field references
      
      This error requires a combination of factors : 
      1. An "impossible where" in the outermost SELECT
      2. An aggregate in the outermost SELECT
      3. A correlated subquery with a WHERE clause that includes an outer 
      field reference as a top level WHERE sargable predicate
      
      When JOIN::optimize detects an "impossible WHERE" it will bail out
      without doing the rest of the work and initializations. It will not
      call make_join_statistics() as well.  And make_join_statistics fills 
      in various structures for each table referenced.
      When processing the result of the "impossible WHERE" the query must
      send a single row of data if there are aggregate functions in it.
      In this case the server marks all the aggregates as having received 
      no rows and calls the relevant Item::val_xxx() method on the SELECT
      list. However if this SELECT list happens to contain a correlated 
      subquery this subquery is evaluated in a normal evaluation mode.
      And if this correlated subquery has a reference to a field from the 
      outermost "impossible where" SELECT the add_key_fields will mistakenly
      consider the outer field reference as a "local" field reference when 
      looking for sargable predicates.
      But since the SELECT where the outer field reference refers to is not
      completely initialized due to the "impossible WHERE" in this level
      we'll get a NULL pointer reference.
      Fixed by making a better condition for discovering if a field is "local"
      to the SELECT level being processed. 
      It's not enough to look for OUTER_REF_TABLE_BIT in this case since 
      for outer references to constant tables the Item_field::used_tables() 
      will return 0 regardless of whether the field reference is from the 
      local SELECT or not.
      8ca8f70d
  5. 31 Aug, 2009 1 commit
  6. 27 Aug, 2009 1 commit
    • Sergey Glukhov's avatar
      Bug#46184 Crash, SELECT ... FROM derived table procedure analyze · d9d71d0f
      Sergey Glukhov authored
      The crash happens because select_union object is used as result set
      for queries which have derived tables.
      select_union use temporary table as data storage and if
      fields count exceeds 10(count of values for procedure ANALYSE())
      then we get a crash on fill_record() function.
      d9d71d0f
  7. 24 Aug, 2009 2 commits
    • Georgi Kodinov's avatar
      Bug #37044: Read overflow in opt_range.cc found during "make test" · e4f8deb2
      Georgi Kodinov authored
      The code was using a special global buffer for the value of IS NULL ranges.
      This was not always long enough to be copied by a regular memcpy. As a 
      result read buffer overflows may occur.
      Fixed by setting the null byte to 1 and setting the rest of the field disk image
      to NULL with a bzero (instead of relying on the buffer and memcpy()).
      e4f8deb2
    • Anurag Shekhar's avatar
      Bug #44723 Larger read_buffer_size values can cause performance · 90032c10
      Anurag Shekhar authored
               decrease for INSERTs
      
      
      Bulk inserts (multiple row, CREATE ... SELECT, INSERT ... SELECT) into
      MyISAM tables were performed inefficiently. This was mainly affecting
      use cases where read_buffer_size was considerably large (>256K) and low
      number of rows was inserted (e.g. 30-100).
      
      The problem was that during I/O cache initialization (this happens
      before each bulk insert) allocated I/O buffer was unnecessarily
      initialized to '\0'.
      
      This was happening because of mess in flag values. MyISAM informs I/O
      cache to wait for free space (if out of disk space) by passing
      MY_WAIT_IF_FULL flag. Since MY_WAIT_IF_FULL and MY_ZEROFILL have the
      same values, memory allocator was initializing memory to '\0'.
      
      The performance gain provided with this patch may only be visible with
      non-debug binaries, since safemalloc always initializes allocated memory
      to 0xA5A5...
      90032c10
  8. 20 Aug, 2009 2 commits
  9. 19 Aug, 2009 1 commit
  10. 21 Aug, 2009 3 commits
  11. 20 Aug, 2009 1 commit
  12. 19 Aug, 2009 2 commits
    • Georgi Kodinov's avatar
      Bug #46019: ERROR 1356 When selecting from within another · 4207e50e
      Georgi Kodinov authored
      view that has Group By
            
      Table access rights checking function check_grant() assumed
      that no view is opened when it's called.
      This is not true with nested views where the inner view
      needs materialization. In this case the view is already 
      materialized when check_grant() is called for it.
      This caused check_grant() to not look for table level
      grants on the materialized view table.
      Fixed by checking if a view is already materialized and if 
      it is check table level grants using the original table name
      (not the ones of the materialized temp table).
      4207e50e
    • Georgi Kodinov's avatar
      0c8690e5
  13. 17 Aug, 2009 1 commit
  14. 13 Aug, 2009 1 commit
    • Davi Arnaut's avatar
      Bug#46013: rpl_extraColmaster_myisam fails on pb2 · 97dbd987
      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.
      97dbd987
  15. 12 Aug, 2009 1 commit
    • 's avatar
      BUG#45516 SQL thread does not use database charset properly · f5be2159
      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 
      f5be2159
  16. 11 Aug, 2009 6 commits
  17. 10 Aug, 2009 2 commits
  18. 08 Aug, 2009 1 commit
    • Davi Arnaut's avatar
      Bug#45010: invalid memory reads during parsing some strange statements · 69fbbdc1
      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.
      69fbbdc1
  19. 06 Aug, 2009 1 commit
  20. 04 Aug, 2009 2 commits
  21. 03 Aug, 2009 2 commits
  22. 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 · 407520b6
      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.
      407520b6
  23. 31 Jul, 2009 1 commit