1. 13 Oct, 2010 1 commit
  2. 14 Oct, 2010 1 commit
  3. 13 Oct, 2010 1 commit
  4. 12 Oct, 2010 1 commit
    • klewis@mysql.com's avatar
      Bug#56632 - The warning code related to KEY_BLOCK_SIZE and ROW_FORMAT when... · f3292c3a
      klewis@mysql.com authored
      Bug#56632 - The warning code related to KEY_BLOCK_SIZE and ROW_FORMAT  when innodb_strict_mode=OFF  is improved in order to take into account whether the KEY_BLOCK_SIZE is specified on the current ALTER statement or the previous CREATE statement.
          
      The testcase shows the expected results of 12 different combinations of these settings.
      f3292c3a
  5. 11 Oct, 2010 2 commits
  6. 05 Oct, 2010 1 commit
  7. 04 Oct, 2010 3 commits
  8. 01 Oct, 2010 1 commit
  9. 30 Sep, 2010 2 commits
    • Vasil Dimov's avatar
      Fix Bug#56340 innodb updates index stats too frequently after non-index updates · e9bd5900
      Vasil Dimov authored
      This is a simple optimization issue. All stats are related to only indexed
      columns, index size or number of rows in the whole table. UPDATEs that touch
      only non-indexed columns cannot affect stats and we can avoid calling the
      function row_update_statistics_if_needed() which may result in unnecessary I/O.
      
      Approved by:	Marko (rb://466)
      e9bd5900
    • Vasil Dimov's avatar
      Fix a potential bug when using __sync_lock_test_and_set() · d70cbd6c
      Vasil Dimov authored
      TYPE __sync_lock_test_and_set (TYPE *ptr, TYPE value, ...)
      
      it is not documented what happens if the two arguments are of different
      type like it was before: the first one was lock_word_t (byte) and the
      second one was 1 or 0 (int).
      
      Approved by:	Marko (via IRC)
      d70cbd6c
  10. 28 Sep, 2010 3 commits
  11. 24 Sep, 2010 3 commits
  12. 22 Sep, 2010 1 commit
  13. 21 Sep, 2010 1 commit
  14. 17 Sep, 2010 1 commit
  15. 16 Sep, 2010 4 commits
    • Sergey Glukhov's avatar
      Bug#50402 Optimizer producing wrong results when using Index Merge on InnoDB · 86d7cbd4
      Sergey Glukhov authored
      Subselect executes twice, at JOIN::optimize stage
      and at JOIN::execute stage. At optimize stage
      Innodb prebuilt struct which is used for the
      retrieval of column values is initialized in.
      ha_innobase::index_read(), prebuilt->sql_stat_start is true.
      After QUICK_ROR_INTERSECT_SELECT finished his job it
      restores read_set/write_set bitmaps with initial values
      and deactivates one of the handlers used by
      QUICK_ROR_INTERSECT_SELECT in JOIN::cleanup
      (it's the case when we reuse original handler as one of
       handlers required by QUICK_ROR_INTERSECT_SELECT object).
      On second subselect execution inactive handler is activated
      in  QUICK_RANGE_SELECT::reset, file->ha_index_init().
      In ha_index_init Innodb prebuilt struct is reinitialized
      with inappropriate read_set/write_set bitmaps. Further
      reinitialization in ha_innobase::index_read() does not
      happen as prebuilt->sql_stat_start is false.
      It leads to partial retrieval of required field values
      and we get a mix of field values from different records
      in the record buffer.
      The fix is to reset
      read_set/write_set bitmaps as these values
      are required for proper intialization of
      internal InnoDB struct which is used for
      the retrieval of column values
      (see build_template(), ha_innodb.cc)
      86d7cbd4
    • Magne Mahre's avatar
      Bug #54606 innodb fast alter table + pack_keys=0 prevents · f43d6c2b
      Magne Mahre authored
                 adding new indexes
      
      A fast alter table requires that the existing (old) table
      and indices are unchanged (i.e only new indices can be
      added).  To verify this, the layout and flags of the old
      table/indices are compared for equality with the new.
      
      The PACK_KEYS option is a no-op in InnoDB, but the flag
      exists, and is used in the table compare.  We need to
      check this (table) option flag before deciding whether an 
      index should be packed or not.  If the table has
      explicitly set PACK_KEYS to 0, the created indices should
      not be marked as packed/packable. 
      f43d6c2b
    • Dmitry Shulga's avatar
      Fixed bug#42503 - "Lost connection" errors when using · be794bc5
      Dmitry Shulga authored
      compression protocol.
      
      The loss of connection was caused by a malformed packet
      sent by the server in case when query cache was in use.
      When storing data in the query cache, the query  cache
      memory allocation algorithm had a tendency to reduce
      the amount of memory block necessary to store a result
      set, up to finally storing the entire result set in a single
      block. With a significant result set, this memory block
      could turn out to be quite large - 30, 40 MB and on.
      When such a result set was sent to the client, the entire
      memory block was compressed and written to network as a
      single network packet. However, the length of the
      network packet is limited by 0xFFFFFF (16MB), since
      the packet format only allows 3 bytes for packet length.
      As a result, a malformed, overly large packet
      with truncated length would be sent to the client
      and break the client/server protocol.
      
      The solution is, when sending result sets from the query
      cache, to ensure that the data is chopped into
      network packets of size <= 16MB, so that there
      is no corruption of packet length. This solution,
      however, has a shortcoming: since the result set
      is still stored in the query cache as a single block,
      at the time of sending, we've lost boundaries of individual
      logical packets (one logical packet = one row of the result
      set) and thus can end up sending a truncated logical
      packet in a compressed network packet.
      
      As a result, on the client we may require more memory than 
      max_allowed_packet to keep, both, the truncated
      last logical packet, and the compressed next packet.
      This never (or in practice never) happens without compression,
      since without compression it's very unlikely that
      a) a truncated logical packet would remain on the client
      when it's time to read the next packet
      b) a subsequent logical packet that is being read would be
      so large that size-of-new-packet + size-of-old-packet-tail >
      max_allowed_packet.
      To remedy this issue, we send data in 1MB sized packets,
      that's below the current client default of 16MB for
      max_allowed_packet, but large enough to ensure there is no
      unnecessary overhead from too many syscalls per result set.
      be794bc5
    • Mikael Ronstrom's avatar
  16. 15 Sep, 2010 14 commits