1. 26 Mar, 2008 2 commits
    • kaa@kaamos.(none)'s avatar
      Merge kaamos.(none):/data/src/bugteam/bug34928/my51 · 12dcd0ed
      kaa@kaamos.(none) authored
      into  kaamos.(none):/data/src/bugteam/mysql-5.1-bugteam
      12dcd0ed
    • kaa@kaamos.(none)'s avatar
      Fix for bug #34928: Confusion by having Primary Key and Index · b753e4a0
      kaa@kaamos.(none) authored
      The bug is a regression introduced in 5.1 by the patch for bug28404.
      
      Under some circumstances test_if_skip_sort_order() could leave some
      data structures in an inconsistent state so that some parts of code
      could assume the selected execution strategy for GROUP BY/DISTINCT as
      a loose index scan (e.g. JOIN_TAB::is_using_loose_index_scan()), while
      the actual strategy chosen was an ordered index scan, which led to
      wrong data being returned.
      
      Fixed test_if_skip_sort_order() so that when changing the type for a
      join table, select->quick is reset not only for EXPLAIN, but for the 
      actual join execution as well, to not confuse code that depends on its
      value to determine the chosen GROUP BY/DISTINCT strategy.
      b753e4a0
  2. 25 Mar, 2008 2 commits
    • davi@mysql.com/endora.local's avatar
      Bug#35272: @@global.key_buffer_size = 4294967295 let the server crash · 079a1748
      davi@mysql.com/endora.local authored
      When trying to get the requested amount of memory for the keybuffer,
      the out of memory could be signaled if one of the tentative allocations
      fail. Later the server would crash (debug assert) when trying to send
      a ok packet with a error set.
      
      The solution is only to signal the error if all tentative allocations
      for the keybuffer fail.
      079a1748
    • andrey@whirlpool.hristov.com's avatar
      Fix for Bug #27944 Filtering THD::client capabilities · 36b83cc8
      andrey@whirlpool.hristov.com authored
      The server used to trust blindly information from the client about
      its capabilities. During the connection handshake the server sends
      information about what it supports and then the client sends back a
      set of capabilities which cover all of the server's or less.
      Before this changeset the server didn't check whether the flags sent
      by the client were valid for the server. For example, if the server
      doesn't support compressed protocol but the client does and sends that
      bit turned on, the server didn't check it. The change make the server code
      less error prone to problems related to the value of THD::client_capabilities.
      
      Clearly there is no vulnerability being fixed but this is a maintainenance
      fix to prevent misusage in the future.
      36b83cc8
  3. 14 Mar, 2008 5 commits
  4. 13 Mar, 2008 2 commits
  5. 12 Mar, 2008 11 commits
  6. 11 Mar, 2008 5 commits
  7. 10 Mar, 2008 8 commits
  8. 08 Mar, 2008 3 commits
  9. 07 Mar, 2008 2 commits
    • aelkin/andrei@mysql1000.(none)'s avatar
      Bug #26622 MASTER_POS_WAIT does not work as documented · 8a4c6521
      aelkin/andrei@mysql1000.(none) authored
      Affected tests fixing. After the fix for st_relay_log_info::wait_for_pos() that
      handles widely used select('master-bin.xxxx',pos) invoked by mysqltest
      there appeared to be four tests that either tried synchronizing when
      the slave was stopped or used incorrect synchronization method like
      to call `sync_with_master' from the current connection being to the
      master itself.
      
      Fixed with correcting the current connection or/and using the correct
      synchronization macro when possible.
      8a4c6521
    • sven@riska.(none)'s avatar
      BUG#31168: @@hostname does not replicate · 81b1d712
      sven@riska.(none) authored
      Problem: in mixed and statement mode, a query that refers to a
      system variable will use the slave's value when replayed on
      slave. So if the value of a system variable is inserted into a
      table, the slave will differ from the master.
      Fix: mark statements that refer to a system variable as "unsafe",
      meaning they will be replicated by row in mixed mode and produce a warning
      in statement mode. There are some exceptions: some variables are actually
      replicated. Those should *not* be marked as unsafe.
      BUG#34732: mysqlbinlog does not print default values for auto_increment variables
      Problem: mysqlbinlog does not print default values for some variables,
      including auto_increment_increment and others. So if a client executing
      the output of mysqlbinlog has different default values, replication will
      be wrong.
      Fix: Always print default values for all variables that are replicated.
      I need to fix the two bugs at the same time, because the test cases would
      fail if I only fixed one of them.
      81b1d712