1. 23 Nov, 2010 1 commit
  2. 22 Nov, 2010 2 commits
  3. 15 Nov, 2010 2 commits
  4. 13 Nov, 2010 4 commits
    • Igor Babaev's avatar
      Fixed LP bug #674423. · 9441a9cc
      Igor Babaev authored
      The patch that introduced the new enumeration type Match_flag
      for the values of match flags in the records put into join buffers
      missed the necessary modifications in JOIN_CACHE::set_match_flag_if_none.
      This could cause wrong results for outer joins with on expressions
      only over outer tables.
      
      
      9441a9cc
    • Igor Babaev's avatar
      Merge · 9259ef4c
      Igor Babaev authored
      9259ef4c
    • Igor Babaev's avatar
      Fixed LP bug #674431. · 4e591173
      Igor Babaev authored
      A non-incremental join buffer cannot be used for inner tables of nested
      outer joins. That's why when join_cache_level is set to 7 it must
      be downgraded to level 6 for the inner tables of nested outer joins.
      For the same reason with join_cache_level set to 3 no join buffer is
      used for the inner tables of outer joins (we could downgrade it to
      level 2, but this level does not support ref access).
      4e591173
    • Igor Babaev's avatar
      Corrected the fix for LP bug 672551. · 6cd2a668
      Igor Babaev authored
      6cd2a668
  5. 12 Nov, 2010 3 commits
    • Igor Babaev's avatar
      Merge · 46fe4318
      Igor Babaev authored
      46fe4318
    • Igor Babaev's avatar
      Fixed LP bug #672551. · d9bbc640
      Igor Babaev authored
      Made sure that the function that copy a long varchar field from the record
      buffer into a key buffer does not copy bytes after the field value.
      d9bbc640
    • Igor Babaev's avatar
      Merge · 47b0f369
      Igor Babaev authored
      47b0f369
  6. 11 Nov, 2010 1 commit
    • Igor Babaev's avatar
      Fixed LP bug#672497. · 92772d6d
      Igor Babaev authored
      Miscalculation of the minimum possible buffer size could trigger
      an assert in JOIN_CACHE_HASHED::put_record when if join_buffer_size
      was set to the values that is less than the length of one record to
      stored in the join buffer.
      It happened due to the following mistakes:
      - underestimation of space needed for a key in the hash table
        (we have to take into account that hash table can have more
        buckets than the expected number of records).
      - the value of maximum total length of all records stored in
        the join buffer was not saved in the field max_used_fieldlength
        by the function calc_used_field_length.
      92772d6d
  7. 10 Nov, 2010 2 commits
  8. 09 Nov, 2010 7 commits
  9. 08 Nov, 2010 5 commits
  10. 07 Nov, 2010 1 commit
    • Igor Babaev's avatar
      Fixed LP bug #671901. · 74d18e93
      Igor Babaev authored
      Currently BNLH join uses a simplified implementation of hash function
      when hash function is calculated over the whole key buffer, not only
      the significant bytes of it. It means that both building keys and
      probing keys both must fill insignificant bytes with the same filler.
      Usually 0 is used as such a filler.
      Yet the code before patch filled insignificant bytes only for probing
      keys. 
      74d18e93
  11. 06 Nov, 2010 3 commits
    • Igor Babaev's avatar
      Merge · bbbe3ac8
      Igor Babaev authored
      bbbe3ac8
    • Igor Babaev's avatar
      Merge · 71e48fbf
      Igor Babaev authored
      71e48fbf
    • Igor Babaev's avatar
      BNL and BNLH algorithms scan the join table and for each its record they · dba8cfd5
      Igor Babaev authored
      try to find a match in the join buffer. It makes sense to check for a match
      only those records satisfying WHERE/ON conditions that can be pushed to
      the scanned table. It allows us to discard early some join candidates.
      
      Such pushdown conditions were built when BNL join algorithm was employed,
      but for they were not built when BNLH algorithm was used.
      The patch removes this shortcoming. 
      dba8cfd5
  12. 05 Nov, 2010 4 commits
  13. 04 Nov, 2010 4 commits
  14. 03 Nov, 2010 1 commit
    • unknown's avatar
      MBug#643463: slow XtraDB shutdown due to 10 second sleep in purge thread · e55c4836
      unknown authored
      Implement os_event_wait_time() for POSIX systems.
      
      In the purge thread, use os_event_wait_time() when sleeping rather than sleep,
      and signal the event when server shuts down, so we do not need to wait for
      upto 10 seconds until the purge thread wakes up.
      
      Also fix bug that warnings that were pushed after we call set_ok_status() were
      not included in the waning count sent to the client in the result packet.
      
      Also in mysqltest, in recursive die() invocation at least print the message
      before aborting.
      
      client/mysqltest.cc:
        If we detect recursive die(), at least print the message before aborting.
      mysql-test/r/warnings_debug.result:
        Test case.
      mysql-test/t/warnings_debug.test:
        Test case.
      sql/handler.cc:
        Force generation of a warning with specific debug option, for testing.
      sql/protocol.cc:
        Fix wrong DBUG_ENTER
      sql/sql_class.h:
        Add method to count warnings pushed after set_ok_status() is called.
      sql/sql_error.cc:
        Also count warnings pushed after set_ok_status() is called.
      storage/xtradb/include/os0sync.h:
        Implement working os_sync_wait_time() for POSIX.
      storage/xtradb/include/srv0srv.h:
        Make the purge thread wait for an event when sleeping, so we can signal it to
        wakeup immediately at shutdown.
      storage/xtradb/log/log0log.c:
        Make the purge thread wait for an event when sleeping, so we can signal it to
        wakeup immediately at shutdown.
      storage/xtradb/os/os0sync.c:
        Implement working os_sync_wait_time() for POSIX.
      storage/xtradb/srv/srv0srv.c:
        Make the purge thread wait for an event when sleeping, so we can signal it to
        wakeup immediately at shutdown.
      e55c4836